Add a `buf login` browser-based auth flow

[lrewega]

I think there is an opportunity to provide a better login experience that removes the need for a user to generate a token and paste it into their terminal. For example:

• buf login [<remote>] opens the user's browser to a page on the remote BSR similar to the current create-a-token page, but specific to this flow.
• The user logs in via SSO with their IdP if necessary -- valid existing sessions are respected.
• The user is presented with a "Approve authenticating the buf CLI" dialog, presses "Approve".
• A short-lived machine token is minted (~24 hours; configurable).
• buf login receives the machine token from the BSR[^0] and persists it to the user's .netrc.

Note that in this flow, the CLI and IdP do not interact at all. There are several assumptions baked into this about what sort of secrets/sessions are shared between the CLI and BSR -- I have several ideas -- but I am more interested in what folks think about this concept.

There would also have to be some way to fallback the current approach e.g. --[no-]launch-browser, etc.

[^0]: there is an implicit assumption in this design that the CLI first performs some sort of handshake or establishes some other relationship with the BSR such that it can wait around for the token to be minted or not[^1]. Some sort of identifier must be included in the URL sent to the browser so the BSR can correlate the CLI and browser sessions[^2]. [^1]: in the case where a token was not minted, either the CLI can wait for the NACK from the BSR or can time out if the URL+identifier wasn't accessed in some short amount of time (O(seconds)) [^2]: because avoiding state is desirable, we could transmit some sort of magic-wormhole-like pre-shared-key such that no new state would be necessary from the perspective of the BSR.

[amckinney]

For reference, there's some prior art that acts very similar to what you're describing in https://github.com/bufbuild/core/pull/399.