Try to be more threadsafe with EOSPAC

I think we've all been trying to develop around the fact that EOSPAC is not thread-safe, but I think maybe we should try to codify some development principles to try to make our EOSPAC classes approach something more like thread safety.

The main issue (as I see it) is that EOSPAC table options can be applied after the class has been initialized. I would propose forcing all EOSPAC table options to be applied only at initialization.

The biggest consequence of this would be that the Transform struct would not be able to be passed to the member functions. If a different transformation was desired, we'd need to create a new EOSPAC class with those transformations applied.

There might be memory usage implications, but I think the EOSPAC memory usage model might try to not load data twice if it can. This hypothesis is worth testing though.

Otherwise, I think this would help with reasoning about how EOSPAC class copying works. It might also reduce the hoops needed for the transformations to be applied.

@rbberger since you wrote this code initially, do you have thoughts? @jonahm-LANL your thoughts are also valuable here

Begin by locating the EOSPAC classes, their initialization paths, and the member functions that accept a Transform struct or apply table options after initialization. Measure whether creating separate transformed EOSPAC instances duplicates memory, then define and test the initialization-only option and copying behavior with the maintainers before implementing it.