Breaking: Turn Z component into a generic property

[josfeenstra]

Closes #18

Hi Hugo! During my work at Foresight we required a TIN for interpolating various attributes.

This change would allow storage & interpolation of any additional attributes.

Breaking changes

• Points in general are now modeled as tuples rather than arrays, so the last component can be generic.
• In situations with sizable generics, cloning starts to become more expensive.

Self diagnose

• Names & api could use some work
• Requires some more examples using different generics, implementing Attr.
• Attr should be easier to implement. A few less traits are probably possible.

[hugoledoux]

hmmmm, quite a big change, I need some time and some further explanations. Especially that startin is also having python and C/Julia bindings, I don't want to break things that work at the moment.

I agree that having 1+ attributes would be good: lidar points having classification, intensity, etc.

But storing in tuples means loads of cloning in practice, as you mentioned... Can't we do better?

One option would be to store each point as a Vec (which contains [x, y, attr1, attr2, attr3, ...]), but that would mean all attributes are f64. Which is not super useful I guess?

One question: with your changes, how would I store one f64 (elevation) and one classification (integer). Would that be possible without modifying lib.rs?

But nice that you are interested in using startin!