Add support for apikey based logins

[dezeroku]

Allows users to log in with client_id&client_secret pair that can be obtained from Bitwarden.
Apikey based login does not return refresh_token as part of the response, instead it's required to just reauthenticate with the credentials (same approach as in the official CLI).

What was changed:

1. New refresh_token type was added to differentiate between the refresh flows required. SSO and email+password return the refresh_key, apikey stores the client_id&client_secret pair instead.
   This means that these credentials are stored on disk in plaintext, in the rbw's DB file.
   It's consistent with how it's done in Bitwarden's official CLI, they do it the same way
2. New client_id field was added to config
3. client_secret is read via pinentry
4. Added some docs

I also cleaned up a bit in src/api.rs, the apikey request is sent in three different places now, it looked bad without these changes:

1. Separated the common "login request" parameters into a separate struct, to not duplicate the values all over the src/api.rs

device_id and email are needed for the relogin with apikey (to run it exactly the same way as the initial login), I've initially kept these alongside client_id and client_secret in the DB, but eventually changed to reading them from config. Thus adding device_id function non-async variant.

Tested (login + token refresh) the changes with all three flows we'd have now.

This topic started as part of #182
According to it, apikey strategy seems to be less fragile than the password based one, so maybe it'd be helpful for debugging issues in the future

CC @pfr-dev

[dezeroku]

I'd like to follow this one with few more changes along the road, but I feel like thse would warrant separate PRs:

1. Only collect the password and try to unseal the vault at the end of rbw login if we're trying to log in with master password
2. Collect kdf information from the login/ endpoint response -> this will allow us to drop the prelogin/ call for SSO/apikey auth methods
3. Remove the register command as it'll be equivalent to rbw login (with apikey) && rbw purge combination

With these changes all the auth strategies will be handled as first-class citizens and not just piggyback on the master password auth method.

BTW I kind of defaulted to using the config file as a single source of truth defining what method we should use.
If you think that passing flags to rbw login would be cleaner I'd be happy to align