Suggestion: Derive disposability checks from known symbols rather than global interfaces

### Acknowledgement

- [x] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

When it comes to checking for disposability (for use with `using`/`await using` declarations), the checker fetches the global `Disposable`/`AsyncDisposable` symbol and runs an assignability test against its type.

This is mostly fine, but this interface is user-mutable, so any script in the project which plays with these interfaces can unintentionally modify the checker's behaviour. For example, a module might declare an empty global interface for backwards compatibility:
```ts
declare global {
interface Disposable {}
}

export interface MyResource extends Disposable {
...
}
```
...which means that all disposability tests will now return true within the checker, if there's no lib.esnext.disposable or similar to populate the interface.

Other checker processes that rely on well-known symbols tend to interrogate the symbol-keyed properties directly, rather than test against global types – for example, iteration checks first fetch the well-known `Symbol.iterator` via `getPropertyNameForKnownSymbolName`, then use this index to access the iteration method on the target type.

While not critical, it would be an improvement if the checker could test against the `Symbol.dispose`/`Symbol.asyncDispose` properties directly, rather than testing for assignability against the global interface.