Unconditionally require keyring

[jaraco]

In #519, it's become apparent that the optional importing of keyring adds a substantial burden to the project's maintenance, especially after adding type hints. Previously, the main way to opt out of keyring support in twine has been to avoid installing keyring, but as subsequent work showed (#338), that interface was insufficient.

The intention of keyring is to be installed and only to have any non-degenerate behavior when the environment indicates such behavior is relevant (i.e. a meaningful password system is present).

In keyring 15.1, released over a year ago, an additional feature, the --disable keyword was added for a user to easily disable keyring functionality.

I'd like to consider for twine to unconditionally depend on keyring and rely on --disable for users that require to disable this functionality.

[sigmavirus24]

So long as the option isn't so vague as to be literally --disable for twine, I'm +1 on providing a way to disable Keyring without the hack of not installing it.