Right now this is just a test for include directory and linker issues,
but it'll also be necessary when we're actually using netgen...

This doesn't really do anything but create and delete an empty mesh,
but it helped me work out more linker and namespace issues, and it'll be
a good place to put tests for any issues that we suspect aren't in our
shim code.

We need a lot more here but this is a start

Fortunately recent clang versions flag this with a warning and our CI
for them treats warnings as errors.

Let's mark the newly-virtual functions "override" in the subclasses
while we're at it.

In the medium term I'm hoping this will be robust enough to leave on by
default; in the short term I want our CI to yell at me about any errors
this triggers.

We don't use it yet, we don't have plans to use it in the near future,
and if cmake thinks we want it but can't find it then it refuses to
build the parts of netgen we do use.

We don't need it, and it demands Tcl/Tk which we may not have and may
not want to download.

Our Civet recipe was complaining about the lack of pybind11, but I've
seen other weird Python errors here too.

This lets us (re)tetrahedralize volume meshes by turning their
(outermost) surface into a surface manifold fitting our existing API.

We'll still need to tweak this to save interior points as Steiner points
for compatibility with our 2D triangulator behavior.

Why did I not have this API take a reference???

Ought to fix that and deprecate the existing one...

Predicated on tet support in all_tri(), of course...

And get rid of an annoying unimplemented declaration (we have the
functionality under another name though) while we're at it.

This isn't going to be as useful as I'd feared, if we can't support
no-refinement cases, but it's done and it's working for auto-refinement
cases.

This fixes our header check; we can't get away with a forward
declaration if we're asked to generate an UnstructuredMesh destructor.

I don't think the move here should require unstructured_mesh.h but my
compiler disagrees.

We need a bit of a trick here to make sure the autogenerated headers
only get generated once.

gcc probably shouldn't accept this either, but is getting it indirectly.