Topic: Rethinking internalstatetype

Some thoughts on ISTs:

The way we control internal variables right now has some obvious disadvantages;
1. arbitrary numbers (input file aren't human parseable without looking up stuff)
2. merge conflicts (which also change numbering, so input files from prior to a merge also need updating.
3. It doesn't allow users to link in external material models without changing this monolithic enum.
4. We have had many bugs related to voigt notation etc. due to the unwieldiness of huge switch-case statements.

I think going for strings representation would pay off here.
It *might* be costly (I'd really benchmark it before I would make this claim), but we could easily do something about that with some simple hashing.

I think the names should be along the lines of some standardized values; stress, strain,
or maybe even single letter representations like "F" (deformation gradient).

The input file would then look like

vtkxml tstep_all domain_all cellvars 2 F S ...
...
#ELEMENT step 1 number 1 gp 1 keyword F component 1 value 1.2345

I think we should deal with "temp" vs nontemp values through a separate flag rather than listing them.

Implementation I don't think we should just use a raw string straight off, but rather embed a simple class

class InternalStateType {
private:
    std::hash<...> hash;
public:
    std::string name;
    InternalStateValueType size;
    InternalStateType(std::string name, size=ISVT_UNDEFINED):  hash(name), name(std::move(name)), size(size) {}
    inline bool operator==(const InternalStateType &t) { 
        if ( hash != t.hash ) return False;
        return name == t.name;
    }
}

It's probably not at all necessary to use a hash, especially not if we keep to short strings.

We can still have code that specify the ISTs as readily available variables:
InternalStateType IST_StrainTensor("stress", ISVT_TENSOR_S3);

This bundling with the InternalStateValueType lets us skip the unwieldly switch case.