[Identity] Should we separate InteractiveBrowserCredential? One for Node, one for the browser.

[sadasant]

InteractiveBrowserCredential currently can be used in Node and in the browser, however:

• In the browser, the AAD apps have to be of type SPA, while in Node they have to be Web.
• In the browser, clientId is necessary.
• In the browser, we allow passing configuration like "loginStyle".

I believe we started these thinking of an isomorphic experience because we were overly optimistic, but at this point it's clearer that these two are fundamentally different, and it will be hard to keep them related.

[ramya-rao-a]

For the moment, we will keep the InteractiveBrowserCredential as is and focus on clearer docs where we talk about client side and server side applications separately like we have started to in http://aka.ms/azsdk/js/identity/examples

#14909 captures our plans to not have a v2 at the moment. This would mean that the implicit auth flow in InteractiveBrowserCredential will be the default, while the auth code flow is opt-in. When auth code flow is chosen and clientId is not provided, we will throw an error.

The MSAL team already has @azure/msal-browser, @azure/msal-react and @azure/msal-angular. Before making any further high stakes changes in the our auth story in the browser, it is worth syncing with the MSAL team and plan the charter together.