[python] Vendor corehttp and coreidentity for 3P

We want to be able to generate a "dependency-less" SDK, that do not depend on corehttp and coreidentity

```
mynamespace/
├── __init__.py
├── _vendor
├──── _corehttp
├──────exceptions.py # Alias to _vendor.corehttp.exceptions
├────── credentials.py # Contains only thee credential alias that the TypeSpec declare (if API key, only alias ApiKeyCredential)
├── _client.py

└── other_files.py
```

Should not be the default behavior, should work for 3P for now (azure-core or azure-mgmt-core vendoring is not needed or wanted for Azure)

Flag could be called `include_corehttp` or maybe `include_runtime`. I'd like a generic name

In terms of how we want to achieve vendoring code from `corehttp` and `coreidentity`, what we will want to do is when we build our generic emitter, we want to copy paste over pinned versions of these modules into our `dist` / `node_modules`. We also want to do a regex replace on these files, because `coreidentity` will depend on `corehttp` and import from that module, we want to make sure that all of these imports are now relative instead of to another library. Then if a user wants to generate with vendored `corehttp` and `coreidentity`, we just dump the files out from `dist` / `node_modules` at the end of generation into the `_vendor` folder.

We will also need to make sure that if we are vendoring `coreidentity` and `corehttp`, we change our dependencies in the `setup.py` we generate. Make sure we remove the `corehttp` dep in the generated setup.py, and add `httpx` or `authlib` or whatever is needed.

COpy-paste from @lmazuel email

- [ ] All vendor should go in a "_vendor" folder.
- [ ] Should be a flag for codegen like "vendor-runtime: true"
- [ ] Vendoring implies different setup.py dependencies
- [ ] NPM package should include pinned version of those packages, with import of "coreidentity" already "regexp replaced" to load relative code (from ..corehttp).
- [ ] If TypeSpec doesn't have OAuth or bearer token, do not vendor "coreidentity"
- [ ] The alias we will put in place (for TokenCredential, ClientSecretCredential, etc) should match what the TypeSpec expecta. For instance, if the TypeSpec is just about OAuth, no need to alias "KeyCredential".
- [ ] Always alias all exceptions when we vendor