Alternative Version implementation

[David M. Lloyd]

I've gone ahead and written a new Version implementation that implements 
the rules I've described.  It seems to work OK though I am having a hard 
time running all tests locally due to some environmental problem that 
I'm still working on, so I don't have a webrev yet.  But I do have a 
diff that can be examined (and commented upon) at [1].

The features of this implementation are:

* Defines a single, unified version syntax and collation order without 
defining a versioning policy
* Internally only contains one field, a String, which should provide a 
minimal memory footprint compared to the multiple List approach
* Can be iterated piece-wise using a public Version.Iterator class (also 
lightweight), which allows user-defined validation via e.g. 
Predicate<Version> to be easily implemented
* Internal validation and collation logic uses a simple objectless 
iteration (tokenizer-based) system by way of "cookie" values that 
represent iteration state, which are reused by the aforementioned 
Iterator class
* A bit more Unicode-friendly, as iteration operates on a code point 
basis rather than on a character basis

The unresolved issues of this implementation are:

* It was my intention to apply Unicode normalization to the input 
String, however the Version class is required to be used at an earlier 
stage than Normalizer can be used so there's a bootstrap-related NPE if 
that code is enabled
* There is no hook to provide a layer-specific validation policy; 
Configuration seems to be the logical place for this but it's not clear 
how it can be hooked in to the resolution process because of the tight 
coupling between Configurations and resolution... resolving 
#ModuleNameCharacters will probably provide an answer to this as well
* Needs additional dedicated tests (all testing thus far has been manual)
* Need to review/examine/discuss the collation rules (particularly 
around separators), which I mainly just pulled out of my hat, to 
determine what makes the most sense from a first-use perspective as well 
as a compatibility perspective (OSGi, Maven, packaging systems etc.)

I will follow up with a webrev at some point in the future unless anyone 
wants to discuss or possibly reject this approach.  Rémi has already 
pointed out that a plain version String is possibly the simplest/best 
approach; I think part of this discussion must revolve around whether 
unifying on a version system is desirable.  My position is that there is 
value to be gained by unification (particularly around a common 
collation scheme), but the compatibility path may be a tricky one.

[1] https://github.com/dmlloyd/openjdk-modules/compare/jigsaw/jake...version
-- 
- DML