Make BotBuilder an HTTP server adapter instead of an App plugin.

Why: BotBuilder participates at the inbound HTTP layer. Modeling it as an adapter keeps App plugin DI cleaner and lets Core/App treat BotBuilder as host integration rather than a privileged plugin that reaches back into the server. This also allows us to clean up our plugin DI that is unnecessarily fairly privileged (eg. why do plugins get access to creds, tokens etc). Doing this allows us to then move toward a more layered architecture (similar to .net), where the "core" layer will be the only "more" priviledged layer (with creds, tokens etc), instead of this information being passed around everywhere.

Migration path:

// Before
new App({
  plugins: [new BotBuilderPlugin({ handler })],
});

// After
new App({
  httpServerAdapter: new BotBuilderAdapter({ handler }),
});

If you already construct a BotBuilder CloudAdapter:

new App({
  httpServerAdapter: new BotBuilderAdapter({ cloudAdapter, handler }),
});

If no cloudAdapter is supplied, BotBuilderAdapter constructs one from explicit credentials, MicrosoftApp* environment variables, or the same CLIENT_ID / CLIENT_SECRET / TENANT_ID env vars used by teams.apps.

Interesting bits:

• Adds BotBuilderAdapter implementing IHttpServerAdapter.
• Removes BotBuilderPlugin and its DI dependencies.
• Cleans up now-unused App plugin DI entries for raw tokens, raw client, metadata, and credentials.

Reviewer tips:

• Start with packages/botbuilder/src/adapter.ts.
• The key thing to check is whether the adapter wrapper preserves the previous BotBuilder flow before forwarding to the Teams handler.

Testing: