Reject non-instantiable geometry types in WKT and EWKT

As a user of the spatial decoder,
I want WKT and EWKT decoding to explicitly identify geometry types that are
defined as non-instantiable,
so that invalid input using an abstract spatial type produces a clear and
meaningful decoding error.

Context

Some geometry types belong to the spatial type hierarchy but are not valid
concrete geometry values.

The project represents this distinction through
GeometryTypeEnum::isInstantiable().

A non-instantiable geometry type is fundamentally different from a valid
instantiable geometry type that is not yet implemented by spatial-types.

Issue #34 introduces NotYetImplementedException for the latter case. A
non-instantiable type must therefore not be reported through
NotYetImplementedException.

The WKT and EWKT strategies must recognize non-instantiable geometry type names
when they occur in input and report explicitly that such a type cannot be
instantiated.

The current non-instantiable values defined by GeometryTypeEnum are:

• GEOMETRY
• CURVE
• SURFACE
• SOLID

The classification must be obtained from GeometryTypeEnum rather than
duplicated as a decoder-specific list.

Acceptance Criteria

• WKT decoding recognizes geometry type names represented by
  GeometryTypeEnum, including non-instantiable types.
• EWKT decoding recognizes geometry type names represented by
  GeometryTypeEnum, including non-instantiable types.
• When the recognized geometry type returns false from
  GeometryTypeEnum::isInstantiable(), decoding fails before attempting to
  instantiate a spatial object.
• GEOMETRY is rejected as a non-instantiable geometry type.
• CURVE is rejected as a non-instantiable geometry type.
• SURFACE is rejected as a non-instantiable geometry type.
• SOLID is rejected as a non-instantiable geometry type.
• The resulting decoder exception clearly identifies the recognized
  geometry type and states that the type is not instantiable.
• The same exception contract is used by both WKT and EWKT decoding.
• A non-instantiable geometry type does not cause a
  NotYetImplementedException.
• An instantiable geometry type that is recognized but not yet implemented
  remains distinguishable from a non-instantiable geometry type.
• An unknown geometry type remains distinguishable from a recognized
  non-instantiable geometry type.
• The decoder does not maintain its own duplicated list of
  non-instantiable geometry types and relies on
  GeometryTypeEnum::isInstantiable().
• Automated tests cover every currently non-instantiable
  GeometryTypeEnum value for WKT.
• Automated tests cover every currently non-instantiable
  GeometryTypeEnum value for EWKT.
• Automated tests verify the distinction between non-instantiable,
  not-yet-implemented, and unknown geometry types.
• Existing decoding behavior for valid instantiable WKT and EWKT geometry
  types remains unchanged.
• A recognized non-instantiable geometry type causes a NonInstantiableGeometryTypeException, implementing DecoderExceptionInterface. The same exception is used by WKT and EWKT strategies.

Expected Error Semantics

For example, input based on a non-instantiable geometry type must produce an
error equivalent in meaning to:

Geometry type "Curve" is recognized but cannot be instantiated.

The exact wording may follow the decoder exception conventions, but the public
message must identify the geometry type and explicitly communicate that it is
non-instantiable.

References

• GeometryTypeEnum::isInstantiable() in longitude-one/spatial-core.
• Issue Story - Report recognized spatial types that are not yet implemented #34, Report recognized spatial types that are not yet implemented.
• OGC Simple Feature Access geometry type hierarchy.
• ISO/IEC 13249-3 spatial geometry type hierarchy.