Clean up tree templates implementation to reduce mypy errors

[plannigan]

Mostly type annotation changes, but also includes a few code tweaks.

Based on how Tree was used in the file, I'm fairly certain that the intended use case is Tree[str]. However, it is possible that this can be mage even more precise with ParseType (and alias for Tree[Token]).

Resolves

lark/tree_templates.py:35: error: Item "Tree[Any]" of "Union[Any, Tree[Any]]" has no attribute "startswith"  [union-attr]
lark/tree_templates.py:36: error: Item "Tree[Any]" of "Union[Any, Tree[Any]]" has no attribute "lstrip"  [union-attr]
lark/tree_templates.py:123: error: Item "str" of "Union[Tree[Any], str]" has no attribute "iter_subtrees"  [union-attr]
lark/tree_templates.py:155: error: Argument 1 to "translate" has incompatible type "Union[Tree[Any], str]"; expected "Template"  [arg-type]
lark/tree_templates.py:155: error: Argument 2 to "translate" has incompatible type "Union[Tree[Any], str]"; expected "Template"  [arg-type]

[plannigan]

Since Transformer has an __init__(), it is best to call it in case it does something more important in the future.

[plannigan]

This annotation for vars was here originally but conflicts with the annotations I've added based on how the code was written. The key issue is that TemplateConf._match_tree_template() returns a dictionary where the value could be a str or Tree[str]. This then ripples up here because translate() uses this result as the vars argument. This could be a case that the annotation on vars was not completely accurate. Or, since it was one of the few annotations used initially, that it is the intended API. If it is the second, then there would need to a second pass on the implementation to have everything line up.