Should Tokenizer Entries have names or be associated with Type atoms?

[luketpeterson]

Question that came up in the implementation of MettaMod::import_item_from_dependency_as
(Think "from module import foo as bar" in Python)

Behavior as implemented:

• If the from_name argument exactly matches a [Tokenizer] entry in the source module,
  then that entry will be imported, and the name argument will be ignored. In this case no
  atom is imported.
• If an exact [Tokenizer] entry was not found, this method will attempt to resolve from_name
  into an atom, using the [Tokenizer] and [Space] associated with the dependent (source) module,
  and the resolved atom will be imported into the &self [Space]
• If name is provided, then if the resolved atom not a Symbol or if the resolved atom is a
  symbol that doesn't perfectly match name, a new [Tokenizer] entry will be created to
  access the atom in the &self module

However this strikes me as very clumsy.

Exactly matching a regex makes importing a Tokenizer pattern pretty unfriendly.
Does it make sense to require Tokenizers entries to be associated with atoms, for
example "Type Atoms"? For example, we could have an "Number" type that is tied to all the
Tokenizer regex patters used to parse different types of numbers? Then a user could
"!(import! Number from Arithmetic)" or whatever, and get all the Tokenizer patters that parse
numbers?

[vsbogd]

Copied from #580 (comment)

Yes, I think it make sense to add some identifiers to the tokens for the importing purposes. It is not a blocker for this PR and can be added as a separate change. I don't think it must be a type. For example if we are importing a token which is create by bind! it is better to import it by a token name rather than by type.