Clarify the form and constraints of target_url

[reinecke]

OTIO has long used target_url as a way to refer to assets referenced by a timeline (such as media files). However the ruleset for how these URLs are formatted has been "wild west" since the fields to store them are strings.

We should explicitly specify how these urls are formatted. Considerations include:

• Convention about URL scheme formatting
• Clarifications and examples for the most common use case of file:// urls
• Clarifications about percent-encoding
• Explicit specification about how to resolve relative URLs to a resource

This work should likely be followed up with some code to assist users in properly constructing and working with these URLs for the common use cases.

[meshula]

I think we should probably follow something like this:

https://restfuljson.org

In a nutshell, string encoding and escaping per: https://tools.ietf.org/html/rfc7159 URL encoding per: https://tools.ietf.org/html/rfc3986

Additional meta-data associated with the media referred to by the URL are specified by https://tools.ietf.org/html/rfc6906

[ssteinbach]

I think in addition to specifying the constraints, we should provide a couple of functions, in C++ and in python, that let you convert from filesystem paths to correctly encoded urls, and back, including support for relative and absolute file paths. The unit tests alone would benefit from this.

Probably be a good idea to add a test of some kind that detects malformed .target_url fields to otiostat and run it on the .otio files in the repo. We could also run it in the unit tests when running self.assertJsonEqual() if we wanted to be really thorough.