Design idea for subarchs/abivariants

[Rich Felker <dalias@aerifal.cx>]

The problem: how to have subarch variants on the bits headers and asm
for a given arch without ugly build system complications or massive
duplication of files.

Proposed solution:

1. $(ARCH)$(SUBARCH)/%.s is searched in addition to $(ARCH)/%.s for
arch-specific files replacing general %.c files in the src tree. This
would allow src/fenv/arm-hf/%.s and src/setjmp/mips-sf/%.s files, for
example.

2. Making bits/endian.h, bits/fenv.h, and any other bits headers that
need to vary per-subarch into generated headers. I think this could be
accomplished with a single rule for generating bits/%.h from
bits/%.h.sh the way alltypes.h is generated now. The full
$(ARCH)$(ENDIAN)$(SUBARCH) could be passed to the script as $1,
allowing simple shell logic to choose the right version to output.

3. Having configure derive separate $(ARCH), $(ENDIAN), and $(SUBARCH)
from the gcc-style machine strings or combined musl-format arch string.

This sounds like it will be minimally invasive and meet the
requirements for supporting subarch/abi-variants.

Comments?

Rich