Harmonize material names and class names

[alexhjames]

Description

For materials.resolveMaterialClassByName() to function, material.name and the class name should be the same. This PR ensures that is true for all materials.

No testing was added as the name field on the material isn't really something to be tested.

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify that the new/changed code works.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes (location doc/release/0.X.rst) are up-to-date with any bug fixes or new features.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in setup.py.

[keckler]

If we're gonna do this, I welcome you to fix all the broken blueprints files in our benchmark models :-)

[john-science]

Approved, pending testing.

[alexhjames]

If we're gonna do this, I welcome you to fix all the broken blueprints files in our benchmark models :-)

I don't think this needed. We ran into this in terrapower-twr a few months ago with T92Depleted vs T92-Depleted-Boron. The blueprints use the class name not the name field.

[keckler]

Well I'll be darned, you're right. Forget my snarky comment!

[john-science]

Two unit tests failing:

Traceback (most recent call last):
  File "/home/runner/work/armi/armi/armi/tests/test_lwrInputs.py", line 67, in test_loadC5G7
    self.assertIn("Uranium Oxide", streamVal, msg=streamVal)
  File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/unittest/case.py", line 1179, in assertIn
    self.fail(self._formatMessage(msg, standardMsg))
  File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/unittest/case.py", line 753, in fail
    raise self.failureException(msg)
AssertionError: 'Uranium Oxide' not found in '[warn] Ignoring invalid settings: fakeBad\n=========== Settings Validation Checks ===========\n[warn] Burn chain already imposed. Skipping 

and

[gw1] linux -- Python 3.8.16 /home/runner/work/armi/armi/.tox/test/bin/python
Traceback (most recent call last):
  File "/home/runner/work/armi/armi/armi/reactor/blueprints/tests/test_reactorBlueprints.py", line 119, in test_materialDataSummary
    self.assertEqual(actual, expected)
  File "/opt/hostedtoolcache/Python/3.8.16/x[64](https://github.com/terrapower/armi/actions/runs/5018906168/jobs/8998833243?pr=1270#step:7:65)/lib/python3.8/unittest/case.py", line 912, in assertEqual
    assertion_func(first, second, msg=msg)
  File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/unittest/case.py", line 1129, in assertTupleEqual
    self.assertSequenceEqual(tuple1, tuple2, msg, seq_type=tuple)
  File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/unittest/case.py", line 1100, in assertSequenceEqual
    self.fail(msg)
  File "/opt/hostedtoolcache/Python/3.8.16/x64/lib/python3.8/unittest/case.py", line 753, in fail
    raise self.failureException(msg)
AssertionError: Tuples differ: ('Custom', 'ARMI', False) != ('Custom Material', 'ARMI', False)

[alexhjames]

@john-science Two unit tests are updated! Sorry I didn't catch those locally

[sombrereau]

@alexhjames / @john-science This broke a few of my internal unittests because of name changes to Uranium Oxide and Zirconium. No big deal, but I think we need to do a better job communicating these kinds of changes ... or maybe on my end listening for these kinds of changes.