Variable name size can impact evaluation time? Or just drop the names

[effectfully]

@kwxm claims that the size of the name of a variable has impact on performance:

Even with unit annotations, textual programs were taking 2-3% longer than flat ones. It looks as if that was because the textual version (which I got by converting the flat file) was full of stuff like (lam i_2594 [ [ i_2591 [ i_2593 i_2593 ] ] i_2594 ]). The evaluator uses NamedDeBruijn terms and for the textual version those names were retained in the AST, but for the flat version the names were all "x", and it appears that the longer your names, the slower your program. An application of termMapNames seems to have fixed that.

I don't believe that this is an issue with the evaluator, but maybe there's some kind of laziness deferring deserialization or whatever to runtime. It would be good to look into this issue.

Alternatively, we can just make the CEK machine parameterized by the type of names (using a LookupName name env class or whatever), so that we don't need to juggle those performance-hurting textual names -- as we should've done originally anyway.

[effectfully]

Closing in favor of a subtask in #5955.