Macro loading needs to change

There are several parts to this proposal to change how
configuration/templating information is fed to (usually)
rpmbuild.

1) per-interpreter macros/helpers need to be moved out of rpm

At the moment, the rpm-build package is carrying a huge number
of build pre-requisites to instantiate convenience macros for
every possible interpreter language. Because the helpers
are carried in RPM, not with interpreters, this leads to RPM being
needlessly de facto blamed because
    This package used to build!?!
and
    This interpreter needs additional convenience macros.

The design flaw is that rpm is expected to maintain an increasingly
complex set of functionalities for every possible interpreter and
for every possible usage case. Instead, per-interpreter convenience
macros/helpers need to be associated with the interpreters, not
with rpm, and *.spec files that use a specific interpreter need
to load per-interpreter convenience macros using the macro primitive
method like
    %{load:/some/path/to/interpreter/macros}
instead of continuing the pleasant pretense that RPM Just Works for
all possible package builds.

2) per-vendor macros need to be collected into a single file

Because of the diversity of dialects of (usually) rpmbuild macros in
common use in distro packaging, and the complex and often arcane
means by which vendors choose to use rpm build, there's a need
to refactor vendor-peculier dialects into a vendor-peculier macro file,
and prevent vendor patching of rpm "default" macros. The existing
mechanisms to support per-this and per-that macros loading are
overkill for most known purposes, and the zillions of places that
vendors are choosing to add configuration/helpers (and then blame rpmbuild)
isn't in anyone's interest.

3) per-mode macros need to be implemented

Currently rpm loads all macros all the time. The existing Mandriva
macros constitute a set of ~500 macros; only ~50 of those macros
are useful to rpm while installing, and even fewer are useful for
other modes like verifying signatures/installs or in queries.