Add FeatureSet class for holding information about mapping format capabilities

[NebelNidas]

Mapping formats now have an associated FeatureSet instance, which provides much improved feature support declaration capabilities compared to the existing booleans.

[liach]

For FeatureSet: since mapping format is mainly used on reader/writer end of the visitor chain, can't this just be replaced by extra mapping flags?

[NebelNidas]

The main motivation behind this addition is to allow for programmatic querying of format features. See SubsetAssertingVisitor for example. Consumer applications might also want to limit their export options available to the user depending on element support, or at least show warnings if information loss may occur when converting to a given format.

[NebelNidas]

The tests are only failing because of #97, apart from that everything works fine

[NebelNidas]

One last question @liach: Would you prefer MappingFormat#getFeatures() or just MappingFormat#features()? Usually I'm a proponent of the get prefix, but format.features() feels more natural than format.getFeatures() IMO.

Edit: After consulting Player, I decided to go with features().

[liach]

JDK prefers no get prefix, but prefers to follow existing style (such as return List vs array, existing get prefix in java.lang.Class). I think get is for mutable properties (not recommended nowadays) while record-style is for immutable.