A design for more generic targets

[frostedoyster]

In order to extend the functionality of metatrain, it would be ideal to have infrastructure supporting more generic targets.

In general, a target is defined by its metadata:

• keys: for example different L values for decomposed spherical tensors
• samples: per-structure, per-atom
• components
• properties: how many "numbers" to predict for each sample (e.g. DOS learning)
  Another essential piece of information to fit arbitrary properties is their "transformation rule" under rotation (Cartesian tensor, spherical tensor(s), etc). This can be stored implicitly in the components (xyz_1, xyz_2 etc for Cartesian tensors, and the usual combination of keys and components for spherical tensors).
  An alternative would be to have some custom classes (SphericalTensor, CartesianTensor, etc) to represent the properties of these targets.

The architectures will have to change to either support these targets or error out as needed. Some of the supporting stack and utilities in metatrain will also have to be adapted (losses, LLPR, etc).

Finally, the I/O would have to be adapted to support high-order tensors. Some changes would be required to both the target sections in the input yaml files, as well as some format(s) that would allow storing the tensors (e.g. flattened tensors in ASE/extxyz, TensorMaps, etc)