feat: support returning of ions and bare elements in `get_chemical_symbols`

[cadenmyers13]

Problem

Currently, Structure.get_chemical_symbols() only returns bare chemical species and does not offer support for returning ions.

Proposed solution

Add an optional input to atom_bare_symbol to return ions. Default is to return bare symbol. We might want to update the function name to better represent this behavior. Its been deprecated so this would just involve changing the atom_bare_symbol to something like parse_atom_symbols.

[sbillinge]

Let's think about this a bit. I suggest we have an attribute that is something like atom_symbols_raw that is just whatever is pulled from the cif file. This could be a list or a dict to keep things compact. Then we can have a parser that tries to interpret it and returns two attributes, something like atom_symbols_short and atom_symbols_long or something like that. Short just strips the ion info, but long keeps the ion symbol, but validates it, so if it is an illegitimate ion it does something....raises an exception or fallls back to short or whatever we decide. The former is probably the behavior we had before (program crashed when it couldn't find the chemical species in the lookup table), the latter is the behavior we maybe have now, or were thinking of having....software ignores the ion info but doesn't crash. If we later add a lookup table that has ion information, the behavior of the software won't change but it will silently start pulling the ion information. Something like that.

What I like about this approach is that we start keeping all the information....the raw string that was loaded, our best effort at turning it into an ion, and the bare element. These can then be obtained separately by the user as an attribute in the future as needed. What do you think?

[sbillinge]

Simon copy pasting this from the original discussion in PR #187

@sbillinge Yes makes sense. all atoms get passed through the atom_bare_symbol function which strips all the symbols and only returns species. The challenge with supporting ions is sometimes the atom passed through is a bare symbol, ion, or something else. For example, the 12-C input for this test,

@pytest.mark.parametrize(
    "symbol, expected",
    [
        ("Cl-", "Cl"),
        ("Ca2+", "Ca"),
        ("12-C", "C"),
    ],
)
def test_atom_bare_symbol(symbol, expected):
    actual = atom_bare_symbol(symbol)
    assert actual == expected

I think its better to put this on a separate PR/issue. I'll make that issue

[sbillinge]

and ....

I agree. I commented on that issue btw. I think I see a better way in general of handling this and I laid it out there. I will merge this PR and this conversation can go there.

When we go to that work, it would be great if we could find examples of all the legitimate but odd ways that people put these things into cif files. I never saw that 12-C syntax before, but I do see that it is some kind of possible standard that someone came up with. I guess it is for inputing isotopes? For example, I could imagine that 13-C could be hte mass 13 C isotope? In any case, one test for each odd but legit case, but later in that issue