[REF-3228] implement LiteralStringVar and format/retrieval mechanism

[adhami3310]

A LiteralStringVar is slightly more complex in that it may be created from a string that originated from a python f-string and have other Var references embedded within it.

If the original _var_value does contain embedded Vars, then the constructor for such a Var would actually return a ConcatVarOperation over all literal strings and embedded Var references.

[linear]

REF-3228 Implement `LiteralStringVar` and format/retrieval mechanism

[masenf]

looks good to the eye.

needs some test cases

[masenf]

do we really need this defined here? my concern is that some subclass adds additional fields, but then doesn't override __hash__ and thus would compare the same as another Var, even though it really was different.

maybe that's not an issue though. i know __hash__ is a bit weird, in that it is used for set/dict operations, but then they use equality for collision detection

[adhami3310]

If it's not defined here we would have to define it elsewhere anyways, so I don't particularly see a way out of it.

Also __eq__ is generally made to use the weird system of comparison to serialize it for the front end instead of actually comparing the two and returning a bool. It feels like this could cause a limitation between true equality and front-end equality.

[masenf]

who calls this function? it seems like the functionality is part of LiteralStringVar.create now and the old-style vars don't need the ImmutableVarData

[adhami3310]

It's currently being called in __post_init_ of ImmutableVar. If it's desired we can push the behavior of creating ConcatVarOperation into there so not use this.

[masenf]

i think this is good to go