Tracking issue for unsupported parts of the standard

There are some parts of the standard that we don't yet support or we can't test due to their limited usage, but it would be a good idea to write these down in case they come up.

Unticked features written in bold have (unstable and possibly partial) internal implementations and test suites. Let ticked features be the ones that are stable.

Features in this list without their own issue are not significant enough to be a blocker for a release.

• Functions - Limited testing due to limited ORT support
• Initialisers - Replaceable by Constant, initialisers as input defaults unsupported in ORT. #50
• External tensor data - Currently values that become TensorProto must be kept in memory as numpy.ndarray. How will this affect running type inference, when e.g. attributes are expected?
• Sparse tensors - Mostly seem to have a use in initialisers, but currently their appearances for e.g. Constant are ignored.
• Map value type - Though in the standard and undoubtedly would be useful, I'm not sure if it's possible to create/use one.
• Non-standard (non-numpy) data types - though unmentioned (?) in the standard directly, some operators accept dtypes like bfloat16. We would need to slightly modify our representation to accept this.
• Custom naming - Note this isn't strictly required by the standard for producers but it sometimes comes up (e.g. for partial output evaluation). Since Spox tries to keep errors from reaching ONNX checkers it autogenerates all names. It could be useful to allow the user to use their own naming, or access Spox's, if they really wish to.
• Training, differentiability - This seems to be mostly a preview feature.

Read the linked sections of docs/IR.md and review the existing internal implementations and test suites for one unchecked feature. Narrow the work to a specific support or testing target, with completion defined by stable behavior and passing tests before marking the tracking entry complete.