Refactor of Simplex-oriented Code about wildmeshing-toolkit

[mtao]

Subsequent issues:

• 374
• 375
• 376
• 377

[mtao]

@daniel-zint to continue the discussion in
#369 (comment)
and
#369 (comment)

My main issue here is that currently the validity of SimplexCollection::get_union() and SimplexCollection::get_intersection() are completely ambiguous, as they both depend on std::set_union and std:::set_intersection, which REQUIRE their input ranges are sorted.
see:

• https://en.cppreference.com/w/cpp/algorithm/set_intersection
• https://en.cppreference.com/w/cpp/algorithm/set_union
  As such there are three choices:

1. Add a flag to SimplexCollection for whether it is sorted and branch between different algorithms if the input is not sorted
2. Add assertions / checks for sortedness of SimplexCollection
3. guarantee that a SimplexCollection is always sorted

I much prefer the last option, and I think that there is an easy semantic choice that enables your performance worries AND this semantic:

1. Functions that return a std::vector<Simplex> do not have a guarantee of being sorted
2. Functions that return a SimplexCollection are sorted

The inclusion of a mesh-like object in SimplexCollection is therefore:

struct SimplexCollection {
  public:
    SimplexCollection(const Mesh& mesh, std::vector<Simplex>&& simplices): m_complex(mesh), m_simplices(std::move(simplices)) {}
  private:
  std::vector<Simplex> m_simplices;
  SimplicialComplex m_complex;
  protected:
  void fix_state(); // uses m_complex to sort and unique
};

where

struct SimplicialComplex {
bool less_than(const Simplex&, const Simplex&) const;
bool equal(const Simplex&, const Simplex&) const;
SimplexLessThanFunctor less_than_functor() const;
SimplexEqualFunctor equal_functor() const;
private:
const Mesh& m_mesh;
};

In this case SimplicialComplex is more like a "view" of a Mesh to utilize simplex-specific tools