Finalize URI/IRI resource id (RID?) library

[handrews]

Adding oascomply.resourceid and its various URI/IRI-related classes dramatically simplified things. Some ideas for finalizing this module in M2 (see also #34 for context):

• oascomply.rid is probably the ideal module/subpackage name given that I kept doing import oascomply.resourcied as rid (there are too many URI/IRI classes across at least 4 dependent libraries involved in oascomply to have the class names unqualified)
• although if this is to be split out, then probably uri_iri or something else a bit more obvious would be better than rid 🤔
• The WithJsonPtr functionality should probably be handled with a mixin adding a ptr or jsonptr or ptrfrag or something property rather than with compounding multiple inheritance and overloading the fragment property
• Is it worth trying to associate media types and fragments in some way? To allow indicating the media type rather than selecting the fragment syntax directly?
• Scheme-specific validation should also be a mixin if additional properties (e.g. URN q-component, r-component) are needed
• Consider scheme-specific normalization handlers that can be registered; include file:/ vs file:/// in this; note that normalization is mostly outside of the scope of this project, and aside from file authorities, would be left for future contributions
• Query format handlers (e.g. x-www-form-urlencoded) are probably also mixins, as they would add properties (consider also that urn: would need to apply this to both q- and r-components, I think ?)
• It's worth considering if some mixin ideas could be handlers instead - otherwise, the subclasses are likely to proliferate to handle all sorts of combinations

[handrews]

Note that furl also looks promising, but it does automatic encoding (including of IRIs down to URIs). It does, however, catch the double-port error unlike many libraries. Might be worth considering. It seems very full-featured and might do too much processing up front, though, given how heavily this will get used.

[handrews]

The furl authors also have an orderedmultidict package that looks worth using for x-www-form-urlencoded query strings whether furl is worth using for oascomply or not.

[handrews]

Further thoughts:

• Constructors just parse using rfc3987.parse(), but don't do anything else (possibly unless passed specific parameters)
• Have an rid.global_config() or similar function that determines what validations are performed and other features enabled when...
• ...Class.validate() is called, which returns a validated instance of Class (where Class is one of Iri, IriReference, Uri, UriReference)
• It should probably be possible to perform validations manually after construction, but it might end up being better to just handle validations as constructor parameters - use case for incremental validation unclear

rfc3987.parse() already does the fundamental syntax validation. rid.global_config() would enable things like scheme-specific validations; the cost of checking the global config can by bypassed by just calling the constructors directly

Also, unless the global config mandates some level of pre-parsing, additional parsing is not done unless/until properties are accessed. So all classes might have a jsonptr property for JSON Pointer fragments, but it will only attempt to build a JsonPtr instance if accessed. Likewise, q_component and r_component properties will raise errors unless the scheme is urn (it's an open question as to how many properties to add for various URI schemes, but the general philosophy is "make them all available and assume the caller will use them correctly")

[handrews]

rfc3987 cannot be used due to GPL. For now, we will use jschon's URI class, which is backed by rfc3986, as it is adequate and will make things consistent. jschon has agreed to adopt a better URI/IRI class if/when one is available, which is something I will work on separately from this project. But will help this project when it is fixed upstream.

[handrews]

The rfc3987 library has been removed on the m2 branch