The current plan for supporting native DFM libraries is to expose assembly-generated shims for required methods.

This should yield a less impactful binary size hit as compared to the original component-build-leveraging approach, but the impact is still non-trivial.  These things should be done:

- Assess whether we can use digit@'s lookup table approach, in lieu of the current individual shim approach.  This choice affects the remaining points.

- Exactly measure the base library size increase due to exports.  Note that to do this fairly, the delta should be computed between the base library with no VR AND no exports, to no VR with exports.  That is, do not conflate the savings of removing VR with the overhead of supplying the exports.

- Determine how we'll hash the symbol names in the export/import shims to minimize the size of the dynamic symbol table.