2.3.0

2.3.0 - Coexistence with xmsextractor, and seed speeds

Two changes, both needed before a client can seed glyphs from a viewport
lattice rather than from the grid's own points.

xmsgridtrace and xmsextractor can now be imported together

This module registered DataLocationEnum, which is xmsextractor's type, under
the same name xms.extractor registers it. pybind11's type registry is
process-global, so whichever module imported second raised

ImportError: generic_type: type "data_location_enum" is already registered!

The failure was symmetric - it did not matter which order you imported in -
so the two wheels were effectively mutually exclusive in one process, and
anything that traced could not also extract.

The registration is gone. Nothing here needed the export: this module's
location arguments are strings, converted to the enum as a local inside
add_grid_scalars_at_time, so no signature changed and no call site moves.

If you were reaching for the type itself off xms.gridtrace, it is at
xms.extractor._xmsextractor.extractor.data_location_enum. The extractor
package does not re-export it under its public name either, so that is the
only spelling available - there is no tidier one to offer.

New: GetSeedMagnitudes / get_seed_magnitudes

Reports the speed of the field at each seed, at the moment it was released.
A caller sizing a glyph by speed would otherwise interpolate the field a
second time; the tracer already interpolates at the seed to start the trace,
so asking it is free, where doing it outside costs another point-location
search per seed against the same triangulation.

It measures the field, not the tracing: the value is recorded before the
vector multiplier is applied. It is two-component - sqrt(vxvx + vyvy) -
because the tracer is two-dimensional and never reads a z velocity.

A seed the tracer never evaluated reports XM_NODATA, not 0.0. Zero is a legal
speed - a seed sitting in still water measures zero and exits
GTEXIT_ZERO_VELOCITY - so the two must not share a value, and XM_NODATA also
falls outside any magnitude filter rather than passing one with a minimum of
zero. Which unevaluated case it was (not started, waiting for a later time
step, not traceable, extraction failed) is in GetTraceResults' exit reasons.

Like GetTraceResults, this reports the batch: empty before StartTraces and
after a refused one, and untouched by TracePoint, which traces through its
own state.

Fixed: start_traces now discards a refused batch

XmGridTraceImpl::StartTraces clears the batch before validating, but the
Python binding raised on a points/times length mismatch before calling it.
A caller that caught the ValueError could then read the previous batch back
through get_trace_results as though it belonged to the new seeds - and zip
stale speeds against new points. This contradicted the binding's own
documented "starting a batch discards any previous one". It now refuses
through StartTraces first, then raises.

Compatibility

GetSeedMagnitudes is declared after GetExitMessage, so it appends a vtable
slot rather than shifting the ones above it. It is a pure virtual on a public
abstract class, so an external subclass of XmGridTrace must implement it;
callers using the New() factory are unaffected and need no changes.

This is a minor release for the same reason 2.1.0 was, which added four pure
virtuals to this interface.

Dependencies are unchanged from 2.2.0: xmscore 7.0.13, xmsgrid 9.1.1,
xmsinterp 7.0.12, xmsextractor 10.0.10.