DRAFT: Changes/fixes for adjset generation.

[BradWhitlock]

I've been running into a problem with adjset generation where points on either side of a domain will have scrambled point index orderings in the adjsets. If one uses the adjsets to index into the coordsets, it is possible to get points that do not match on either side of a domain interface. I figured out this happens because of the distance and tolerance comparison in ffloat::operator<. Apparently, we get points that are closer than CONDUIT_EPSILON (1.e-12) and the less than comparison fails. This affects PointTuple::operator< and ultimately the index at which new entities are inserted into the entity vector used to build the adjset.

If the epsilon is decreased then the adjset is fixed for the dataset that causes the problem. This does not seem like a robust enough fix so I'm still thinking about solutions. We should discuss.

Other changes:

• Add some using statements for type readability
• Use accessors to populate the adjset data

[BradWhitlock]

I implemented adjset point sorting based on spatial bins. This works for the Blueprint tests but for some reason, it totally fails on the test problem I've been debugging.

I have some luck with a custom predicate passed to std::upper_bound() that checks whether points are the same within CONDUIT_EPSILON before delegating to PointTuple::operator<. That works. Is it better/robust? Meh.