Define normalization of `path` claim

[bbockelm]

The path claim intends to limit the areas within a given VO's storage that the token is authorized to read/write from.

However, paths are notoriously tricky as //foo and /foo tend to indicate the same directory in Unix.

Open questions are:

• Do we remove extra /?
• Do we allow path names such as . and ..?
  • The underlying question here is whether we adopt a Unix-like model (interpreting these as "parent directory") or a more URL-like model.
  • URL-like model acknowledges that this lives in the context of an HTTP-centered ecosystem. Unix-like model acknowledges the underlying storage, today, is based on Unix concepts.
• What byte values / encoding are allowed in the path?

Honestly, if we had a handy RFC for normalizing paths (maybe the one defining URLs?), I'd be satisfied. I don't think I have a strong opinion here; mostly, I want things to be unambiguous, adhere to rules maintained by someone else, and easy-to-validate.

[bbockelm]

@jbasney - I'd like your input on the big-picture direction here and whether there is any RFC we should go and reference.

[bbockelm]

This is addressed by #7.