…r context.

Previously, the following test case produced an erroneous diagnostic:

```
class A {
  init() {}
}

@available(macOS 12, *)
class B: A {
  @available(macOS 12, *)
  override init() { // error: overriding 'init' must be as available as declaration it overrides
    super.init()
  }
}
```

The overridden `init()` constructor is as available as it can possibly be. Removing the explicit `@available` annotation suppressed the diagnostic.

To fix this, we check to see if the override is as available as its self type and accept it if it is.

You may be wondering how this works when the `@available` annotation is removed from `override init()` in the example. It turns out that `AvailabilityInference::availableRange()` returns a result that is based only on the explicit availability of the decl in question without taking the availability of the context into account (except when the context is an extension). So with the explicit annotation gone, both the base `init()` and the override are both considered to be "always" available. This is pretty unintuitive and arguably wrong. However, it seems like a lot of existing code depends on this behavior so I've left it for now.

Resolves rdar://96253347