Use OAuth 2.0 to obtain pinning service access token

## Current situation

At the moment, configuring a pinning service requires a few manual steps:
- Accessing the pinning provider (e.g. Pinata)
- Creating an access token on the API Key management UI of the provider
- Figuring out the desired scope of actions the key should allow
- Pasting the access token on the client (IPFS WebUI settings page)

While the experience is already quite simple for the current IPFS audience, it could be improved for lazy and/or less technical users, in line with the purpose of IPFS WebUI.

## Possible improvement: OAuth 2.0 authorization flow

### User experience

With Pinata for instance, the UX would be:
- From WebUI, I click on Pinata icon. I'm directed to Pinata's consent page, showing IPFS WebUI logo and name, as well as the desired scope (around the lines of "Manage pinning").
- I click on "Authorize".
- Et voilà. I'm back to my WebUI instance and the provider is configured.

### Technical changes

- Decide on (and document) a client_id constant, say `ipfs_webui`.
- Implement (and document) a callback page that receives the OAuth 2.0 response after the user has granted access, and does the token fetching logic. There are libraries that help greatly with that bit.
- Define (and document) one or several scopes based on consent granularity. I'm not familiar with the feature enough yet, but one scope might be enough at first, e.g. `pinning`.
- Add a clickable button to send the user to the provider's authorization endpoint, with the proper client_id, redirect_uri and scope (the same libraries can generate that link too).
- Currently that would be only for Pinata but the process would be identical for any provider, changing only the endpoints, or even only the base hostname thanks to RFC 8414 and/or OIDC Discovery.
- Possibly also an input box for configuring custom providers.

For reference, on the provider side:
- Expose OAuth 2.0 endpoints (namely the authorization endpoint and the token endpoint).
- Make the token endpoint automatically generate an API key with the right permissions (taken from the scope).
- Register IPFS WebUI as a public client, with logo and name, and the documented client_id and callback URI.

## Additional notes
A similar approach would exist for other clients such as Desktop UI, CLI etc., with different callback URIs (native deep link etc.).