Support a templating api for alternative target representation

[cgruber]

a.k.a smarter snippets.

In cases where you want to substitute the build snippet, but don't want to lose all the computation, we should formalize the values passed to the internal default snippet templates so that external templates can make use of them. This would either mean just making build_snippets itself support these template values (you can use any or all of or none of them, but it'll flag unsupported template substitutions) or make a new separate feature for this, preserving the "override the warranty, you get what you paid for" raw text substitution for emergencies.

Probably making a new feature is preferable, and then seeing if the old feature can be eliminated would be the least disruptive.

The template vocabulary will need to be carefully considered - it should have at least all of the fields used by kramer today, but may need to have more, in cases of non-aar/jar/bundle alternatives.

A key use-case here is kotlin, where one might want to not use raw_jvm_import but substitute kt_jvm_import, or do something similar, across a large group of artifacts, where using string replacement and taking over all the deps management would obviate the value of the BMR system itself.

A subtask of #52