namespaces: record and expose whether namespace is built-in Currently, the templating layer tends to treat each namespace as a one-off, with explicit usage of {bookmarks}, {tags}, {branch}, etc instead of using {namespaces}. It would be really useful if we could iterate over namespaces and operate on them generically. However, some consumers may wish to differentiate namespaces by whether they are built-in to core Mercurial or provided by extensions. Expected use cases include ignoring non-built-in namespaces or emitting a generic label for non-built-in namespaces. This commit introduces an attribute on namespace instances that says whether the namespace is "built-in" and then exposes this to the templating layer. As part of this, we implement a reusable extension for defining custom names on each changeset for testing. A second consumer will be introduced in a subsequent commit.

templatekw: expose color name in {namespaces} entries Templates make use of a "log.<namespace>" label. The <namespace> value here differs from the actual namespace name in that the namespace itself is plural but the label/color value is singular. Expose the color name to the templating layer so log.* labels can be emitted for {namespaces}. As part of this, we refactored the logic to eliminate a gnarly comprehension. We store color names in their own dict because the lookup can occur in tight loops and we shouldn't have to go to repo.names[ns] multiple times for every changeset.

show: construct changeset templater during dispatch Previously, we constructed a formatter from a specific template topic. Then from show() we reached into the internals of the formatter to resolve a template string to be used to construct a changeset templater. A downside to this approach was it limited us to having the entire template defined in a single entry in the map file. You couldn't reference other entries in the map file and this would lead to long templates and redundancy in the map file. This commit teaches @showview how to instantiate a changeset templater so we can construct a templater with full access to the map file. To prove it works, we've split "showwork" into components.

cmdutil: use named arguments for changeset_templater.__init__ This will make the API more extensible and easier to use.

bundle: inline applybundle1() We have now gotten rid of all but one caller, so let's inline it there.

bundle: make applybundle() delegate v1 bundles to applybundle1()

bundle: transpose transaction scope with bundle type switch This moves the transaction with-statements outside of the per-bundle-version switches, so the next patch will be a little simpler.