Support changing interpretation of support values as node names

## Problem

Currently, QIIME 2's trees (at least the _de novo_ moving pictures tutorial one we've been using) have support values\* encoded as the names of internal nodes:


(The alphanumeric hashes are tip names, which correspond to DADA2 feature IDs.)

Empress interprets these as "node names," which is technically correct (they are names in the Newick file) but practically incorrect (they're not really "names"). This doesn't make that much of a difference for us, but this behavior has apparently been a problem with other tree viewers that support re-rooting based on these values:

https://www.biorxiv.org/content/10.1101/035360v1.full

\* iTOL says they're bootstrap values, but this tree was made using FastTree (using [this pipeline](https://docs.qiime2.org/2020.8/tutorials/moving-pictures/#generate-a-tree-for-phylogenetic-diversity-analyses)), and it looks like FastTree generates ["local support values"](http://www.microbesonline.org/fasttree/#Support) which seem similar to bootstraps but not identical. I think bootstrap values are a type of support value, so just calling these "support values" in the Empress UI is probably the way to go...?

## Proposed changes

It would be nice to either:

1. Figure out (using QIIME 2 semantic types or whatever) what internal node names "mean" in a consistent way, so that we can adjust the interface accordingly.

2. Allow the user to specify in the CLI how to interpret internal node names (this is ok, but similarly to #348 the whole QZA thing means that many users likely won't bother looking at the Newick file and so likely won't care/notice one way or another).

3. Add a disclaimer to the docs saying "hey we assume the names in your Newick file are actual names, if they aren't it's your problem"

For options 1 and 2, if we know 100% that the names are support values, then we can give the internal nodes all arbitrary names (e.g. `EmpressNode123`) and then store the support values in another array alongside `lengths` or whatever when we address #179. That way, we avoid misrepresenting these values as names.

This isn't really an important issue now, but if we add re-rooting functionality later then it would be good to sort this / #179 out, if only to avoid incurring the wrath of phylogenetics experts ;)

No files or tests are named in the issue. Start by tracing how Empress reads internal Newick node names and exposes them in the UI or CLI; review QIIME 2 semantic-type handling and the related #179 and #348 discussions. Done requires choosing between semantic detection, a CLI option, or documentation, then ensuring support values are not presented as node names.

Written by the indexing model from the issue text.