Support for expandable environment names

[tkw1536]

Currently LaTeXML only has support for environments which are named literally, i.e. those of the form:

\begin{somename}
 content
\end{somename}

However, if an environment name is defined by an expandable token, like in either of the following, LaTeXML fails:

\def\somecs{somename}

\begin\somecs
 content
\end\somecs

\begin{\somecs}
 content
\end{\somecs}

LaTeX itself supports all three cases.

This PR resolves the problem by expanding the argument to \begin and \end. It furthermore adds appropriate test cases to t/expansion/environments.tex.

The solution implemented in this PR is to manually call Expand() on the argument. I also tried making the argument of type Digest, as well as manually Digest()ing the argument, however both of these cases caused test failures. The same goes for using the Expanded argument type.

[dginev]

question: Shouldn't this be realized via the parameter type? E.g. replacing the \begin{} via an \begin XToken or such? cc @brucemiller

[dginev]

Also, if $name is undefined / empty we probably want to throw an error

[brucemiller]

Well, yeah, sorta, but ... No. There's an Expanded parameter type which we tried to use. It failed because it kinda expands too early(?). Well, really LaTeX gets the argument which might be balanced braces or a single token, eventually that gets expanded. Using Expanded caused latexml to only see the 1st char of the expansion instead of the whole thing; adding extra braces mucked things up differently. It's probably true that one would need (at least) two separate flavors of "expanded"...

[dginev]

Right, it looks like we need a ->readXArg rather than a ->readXToken, and since we don't have that yet, the current PR makes sense

[dginev]

But this begs the question if the Expanded parameter type is ever the correct type to use? Maybe it just needs an upgrade, even separately from the \begin case.