add checked attribute view and float generic in compute centroid

[dan-jfisher]

#23
Downside of this approach is that it requires the user to specify if their pointcloud has f32 or f64 precision.

If it's important, we can maintain backwards compatibility with some clever naming.

\Edit: for centroid, which I used as an example, we could get around that with a private generic function and a public function that always returns f64 and checks the data_type of the point cloud attribute at runtime. I am not crazy about that solution though.

[dan-jfisher]

It would probably be better to take an AttributeView which has already been typed rather than taking the entire cloud. However, if we are going to do that we need to expand AttributeView so that it includes things like len and is_empty.

I am happy to go in that direction though.

[Mortano]

I agree that algorithms over attribute views would probably be better (though some algorithms might require multiple attributes or even mutate data, these would have to take a PointBuffer). If you want to implement it as a PoC for the compute_centroid function that would be fine for me, with the suggested changes (len and is_empty for the views). If not, I'm also fine with merging the changes as is.

Apart from that, for completeness there should be _checked functions for the other view accessors as well, i.e. view, view_attribute_with_conversion and the mutable ones view_mut and view_attribute_mut. Would be great if you could add those.

[dan-jfisher]

What do you think about making view_attribute_checked the default behavior (i.e. view_attribute) and calling the standard function view_attribute_unchecked?

Regardless, I removed that part of PR so that this one is focused on AttributeView and compute_centroid as PoC for generic algorithms.

We can handle view_attribute_checked vs unchecked in a separate issue.

[Mortano]

AttributeView is Copy, so you can pass by value here. This prevents you from having to implement IntoIterator for &AttributeView