Support extension stubs / type augmentation

Overriding existing types and monkey patching sounds based.

```pyi
@extension[str]
class StrExtension:
foo: int

"asdf".foo + 1
```

While often frowned upon(just fix it at the source), it could be also be useful for fixing up third-party packages that have incomplete / incorrect stubs:

Official stub:
```pyi
class SomeThirdPartyClass:
def foo(self, a, b, c): ...
```

vendored stub:
```pyi
@extension[SomeThirdPartyClass]
class _SomeThirdPartyClass:
def foo(self, a: int, b: str, c: bool) -> Foo: ...
```

There would need to be some thought as to how this could be applied to module level declarations, perhaps steal `module` from typescript?

An option to specify overriding vs augmenting would be needed.

Also, should it be a decorator, or part of the class bases?
```py
@extension[str]
class StrExtension: ...

class StrExtension(Extension[str]): ...
```

# Alternative

An alternative to this approach could be a magic module path like `__extensions__`/`__overrides__`. Everything in this folder would mirror the module space(eg: `__extensions__/SomeThirdPartyPackage/SomeThirdPartyModule.py`). Anything in this directory would be applied _on top_ of the base types.

# Additional points

`sitecustomize.py` could be a useful place to do things

The issue does not name implementation files or tests. Start by comparing the decorator or Extension[str] designs with the __extensions__/__overrides__ module-path alternative, then define how augmentation, overriding, module-level declarations, and sitecustomize.py should work. Done requires a settled design and corresponding implementation scope.

Written by the indexing model from the issue text.