Introduce the registry.MacroRegistry class to handle:
* registration of macro types via setuptools' entrypoints
* registration of individual macros for lookup by component list type
* expansion of macros references during YAML "parsing"
As a consequence there is a reduction in performance due to moving the
expansion of macros from inline with XML generation, to requiring
multiple passes over macro component lists.
This decrease in efficiency results in approx ~30-50% increase in unit
test time. Since this will allow for jobs to be expanded from
templates/macros in parallel with future changes, it is a reasonable
short term trade-off as the most computationally expensive task is
updating the definitions on the remote master
Change-Id: I292c6b1f8472370282205426cd8ceb847eb969bd
e645ac2acf