Consolidate version-specific parsers for JGroups and Infinispan subsystems

Currently, both subsystems use a distinct xml parser class for each version of the subsystem schema.  When a new version is created, we copy the previous version and rename it.  The original intent was that a parser for  old schema version would never need to change.  However, since the introduction of resource attributes, changes to the model typically need to be reflected in old parser versions.  Thus the current strategy is no longer tenable.
An alternative strategy, employed by most other subsystems, uses inheritance, where a new version of the parser simply extends the old, overriding specific methods.  This isn't ideal either, especially for subsystems as historically dynamic and large as the infinispan subsystem.  While polymorphism results in less code duplication - it still results in the duplication in most the logic of the method being overridden.  It also can quickly create hard-to-follow spaghetti code.  In general, polymorphism does a poor job of expressing versioned behavior.
Additionally, both strategies lack the ability to quickly discern how the schema has changed across versions.

This PR introduces a new strategy for structuring subsystem parsers for both subsystems.  There is a single parser class which is parameterized by the schema version.  The parsers leverage a since(...) method on the schema enumeration to determine when to apply version specific configuration changes.  Changes are identified by the version that introduced the change.  The condition can be inverted to indicate that a given block of parsing code made obsolete since a given version.  The result is smaller, more intelligible parsing code that is easier to manage and has no code duplication.
Operations are also recorded via a LinkedHashMap - which will be leveraged by a subsequent schema change where a configuration attribute will be move from one resource to another.  The map lets us access previously defined operations by address, while maintaining insertion order, something that will be required by the upcoming configuration change.  This would have needed to be applied to each of the 5 existing parser classes - and was the impetus for this PR.