Fix costly variable exposure mechanism in JSF

The AliasTagHandler logics are widely used through the JSF app, mostly:

• inside layout tags logics
• inside template widget type handler logics
• inside nxu:set tags
• inside nxu:valueHolder tags
• inside nxu:repeat tags, to make sure components state is reset in case of iteration variable change during an ajax request

The mechanism is costly, as it relies on "alias" logics, making possible to reference variables at build time inside AliasValueExpression expressions, held by a managed bean NuxeoAliasBean, and exposed either at build time, either at render time, depending on the context.

Some previous optimizations had already been done, see for instance NXP-12924 and NXP-15050.

Work for NXP-16190 introduced a new way of handling these variables, using a custom VariableMapper implementing blocking logics (to isolate variables exposed inside nested contexts), which may be enough for all variables exposure logics, except maybe (to check) :

• the template widget type handler logics
• the nxu:valueHolder tag
• the nxu:repeat tag
• tags exposing variables at render time (nxd:dataTable, nxu:inputList, nxu:jsInputList)

TODO: test use cases for NXP-11434, NXP-12882, NXP-18639 (not tested automatically, to be checked manually)