Must Destroy OperatorField Objects

[jeremylt]

Fixes #1639

What do we think @jrwrigh. You can see how this does get a bit invasive.

---

Ok, now the Vector/ElemRestriction/Basis retrieved from the OperatorField needs to be Destroyed per the corresponding interface.

[jeremylt]

ToDo: Track down all the CPU memory leaks, add GPU restores, language wrapers

[jrwrigh]

General question is whether the extra check during the restore is worth the new API, or just force the users to call *Destroy on the objects obtained from CeedOperatorFieldGet*.

I'm not sure what bugs the extra CeedCheck(*vec == op_field->vec, ...) would catch.

See later comment for the fluids code that drove me to the above question.

[jeremylt]

Ok, rebased to work off the branch with the lingering Operator memory fix. Impl for CPU ref is in, rest in progress

[jeremylt]

CPU blocked and ref in, GPU non-gen next. (would need to rebase in another open PR to do gen)

OCCA will be annoying so I'm saving it for last

[jrwrigh]

Yeah, all the errors are in the form Error in assembly: 0.0000 != ....

[jeremylt]

Huzzah, at long last. I think this is good to add now, and I can spin up the companion PR to MFEM. Mildly disruptive but not a huge deal as it just leaks if not fixed downstream

[jeremylt]

#1673 takes priority. Will rework this branch after that merges

[jeremylt]

Rebased, manually tested CUDA, HIP. CI won't run on Noether yet due to the failing fluids tests

[jrwrigh]

I'll try and fix those when I get back from lunch and my next meeting (which have now combined into the same event).

[jrwrigh]

(the bin files just needed to be updated if you want to do it yourself).

[jrwrigh]

#1681

[jeremylt]

@jrwrigh CI has been updated, so HONEE can be updated now