Add `pelican token create` utility

[jhiemstrawisc]

I'd like to lump a number of "token creation" issues into a unit of work that adds a pelican token create utility to (mostly) replace the pelican origin token create utility.

Here's what I'm thinking:

The new utility should still have all the power of the pelican origin token create utility, where advanced users can create whatever token they want.

However, for the generic user, we simplify token creation to a command like:

pelican token create --prefix /foo/bar --private-key /path/to/key --reads --writes

This would create a token that can read and write anything under /foo/bar using the key at /path/to/key and some default lifetime -- maybe 20 minutes?

If no private key path is provided, we search the default places and use the same logic for inspecting issuer keys directories for the "best" key.

If the --read and --write scopes are left out, we default to --reads with a notice to the user about the fallback behavior.

A few fields are left out here:

• The issuer
• The subject
• The audience

I think we can do our best to determine the issuer automatically. Given the namespace, we query the Director for the list of issuers, crawl their public keys and figure out which issuer(s) advertise a key corresponding with the local private key. The first match becomes the issuer in the token. One downside to this is that automatic issuer generation requires network access. If no network access exists, or the Director can't be reached, the tool indicates to the user they need to manually select an issuer with instructions about how to do that.

The subject can typically be anything (and we often set it to "anything"), but that's not ideal -- maybe clients have some notion of a "name", in which case I can borrow that and use it as the subject. The best case is that we set the same subject every time the same user invokes the token creation command in the same environment. That being said, subjects must be set appropriately in the case that the origin is running in multiuser mode. We'll have to inspect whether there's a way to detect namespaces backed by multi-user origins, and in those cases warn the user they need to know which username to set as their subject (e.g. HTCondor AP origins would require the user's AP account, and the token would need to reflect that).

The audience typically does need to be the correct "any" string ("ANY" for scitokens and "https://wlcg.cern.ch/jwt/v1/any" for wlcg). The only exception is for direct reads against the origin where an audience could be the origin's hostname:port combo. Even in this case the "any" string should be sufficient, so let's stick with that.

[jhiemstrawisc]

@aowen-uwmad, here's a rough writeup of what I'd like to do for the new token creation utility. I'd love some feedback on proposed token create invocation.