After attempting to tackle this, it turns out there is a good reason to have the duplicate structs around, which is that there's a DLL boundary in addition to the Mojo boundary. We can't use Mojo types across the DLL boundary, as that results in them being auto-freed when going out of scope on a different heap. We need the POD duplicate structs to cross this boundary safely.

It might be possible to modify the Mojo allocation/freeing code to account for this, but that seems like overkill for this test-only code. We could also get away with passing in pointers across the DLL boundary and manually copying the data into them. However, we'd need a pointer for every struct instead of one pointer for the highest level struct since copying a nested struct would result in the same freeing issue. This would result in pretty much the same copying code, just going from Mojo to Mojo instead of Mojo to POD.