refactor support for VAULT_NAMESPACE

[joemiller]

Followup from #21, #23

Support for vault namespaces was not considered in the original design and then added later. It was added by cat'ing together VAULT_ADDR + VAULT_NAMESPACE and using the combined value as the primary key when storing in the OS's credential store.

The problem is that you cannot combine these two values to form a valid URL. This resulted in errors when running vault-token-helper list --extended (workaround/fix in #23).

The workaround implemented may not be correct for all possible VAULT_ADDR values. It works by parsing the combined URL and assuming any Path value is the VAULT_NAMESPACE. This is likely to work for the majority of cases but would fail if the VAULT_ADDR contained a legit /path.

I'm not sure if it is even valid for VAULT_ADDR to contain a path. If not, then this is moot.

A more robust solution would involve storing VAULT_ADDR and VAULT_NAMESPACE separately in the credential store. This may cause some issues with some OS's credential stores. During initial development I ran into some strange issues with (IIRC) the gnome keyring where it would duplicate rather than update existing entries depending on the format of the entry's title.

1. First, determine if VAULT_ADDR containing a path element is valid. If not, then this is likely moot and we can close this.
2. Update to store VAULT_ADDR and VAULT_NAMESPACE
3. Ensure backwards compatibility:
4. When encountering a keychain item of the previous format, upgrade to the new format