[Experimental] Add Typekit for @typespec/http

[joheredi]

This PR includes:

• Consolidating the format used to define Typekits
• Adding @typespec/compiler/experimental/typekit sub export
• Adding @typespec/http/experimental/typekit sub export and implementation

Note: experimental/typekit subpaths were added for improved UX. The typekit import has a side effect which is augmenting existing typekit so having it within its own export isolates the side effect and makes it easier consumers to migrate once it becomes stable into @typespec/compiler/typekit and @typespec/http/typekit respectively

[azure-sdk]

All changed packages have been documented.

• ✅ @typespec/compiler
• ✅ @typespec/http

Show changes

@typespec/compiler - feature ✏️

Add Experimental Typekit helpers for @typespec/http

@typespec/http - feature ✏️

Add Experimental Typekit helpers for @typespec/http

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs	🛝 VSCode Extension

[witemple-msft]

What does a library consumer need to do to activate the new typekit functionality? I am a little weirded out that there doesn't seem to be any import from experimental/typekit from the HTTP library in the tests, so are these new typekits activated automatically on any import of @typespec/http? i also don't see the experimental export path from the HTTP library, only the compiler core.

I think this change is righteous, just want to make sure we have the consumption pattern nailed down for these experimental APIs.

I also worry a little bit about discoverability and how someone is meant to know that import "@typespec/http/experimental/typekit"; ought to be required for its side effects alone to make these extensions available. In the compiler core, you actually have to import $ from the side-effecting path, but here there won't be anything to import, you'll just import nothing from the module and it'll change the behavior of $. Do I have all this right?