Make NuclideBases not global

[youngmit]

The directory in nuclideBases is global, which leads to considerable pain:

• Import order is very sensitive, and lots of things have to happen at import time, and cant happen again or else 💥.
• The actual contents change when a burn chain is imposed, which is really case dependent and can only happen once, or else 💥
• Some code changes the LFP properties, and these changes probably don't survive round-tripping through the database. Not exactly related to global state, but part of the reason we haven't been thinking of it. See collapseFissionProducts and updateYieldVector methods within the fissionProductModel.

So, we should be thinking of another place for this to live, and spin up an object containing the valid nuclides for that scope. Reactor? Case? Somewhere else? Even a global database that is actually an object instead of a magical singleton-esque horror would be better than it is now. Also, if it is mutable beyond the initial setup with a burn chain, then we need to think about how to recover it's state from the database.

[jakehader]

We made a step in a direction where global nuclide bases are less bad than they used to be by adding more nuclides in #998. Unfortunately, the nuclide data is still global and the burn chain modifications still may occur when it's being imposed. I specifically added logging statements if a user overwrites any default parameter from the burn-chain.yaml or custom file, but the transmutation and decay data that is a subset of the nuclides still gets modified based on the user-defined burn chain data.

We can probably take this further still.

[john-science]

@opotowsky

This has reared it's head again, and will have to be put on the calendar for ARMI 0.4.0. It turns out ARMI enforces everyone to use RIPL nuclear data, but we have some users that use ENDF in other parts of their modeling chain. So I would LOVE to give people a setting to choose which nuclear data they want. But we can't do that (easily) if the nuclear data lives in the global scope at import time.

So, finally, I think we have enough interest to make this ticket happen.