MS COFF support for /OPT:REF. [diff]

1. Stock coffms.inc errors on section names over 8 bytes. I extended include\format\coffms.inc: long names spill to the string table with `/nnnn` headers; a new comdat section attribute emits IMAGE_SCN_LNK_COMDAT plus the aux section-definition record; and public static of a section label now records the real section number (it previously emitted an absolute symbol), so it can serve as a COMDAT leader for data.

2. Plain sections are not stripped by either linker — `/OPT:REF` only GCs COMDATs, and a COMDAT needs a leader symbol. Convention: public <fn> right after the code section, public static <first_label> right after each data section. Verified against both lld-link and MSVC link.exe (VS 18): unreferenced functions and their data vanish, referenced ones survive, exit codes prove correct data flow.

This makes object file creation much more useful as whole libraries can be authored in one file. See attached example.

A more hardened, featureful COMDAT support has landed. This resulted from trying to break the prior implementation in various ways. "comdat exactmatch" is the only unsupported feature, and that just requires a postponed CRC32 update.

It'd be helpful if other's tried to break it and post your problems?

I've finished the COMDAT support by adding post CRC32 calculation to support exactmatch. (Similar to prior work in unPNG.) One might want to read, the implementation notes to resolve/modify for their needs; or even some insight into, "WTF are COMDAT sections and why would I want to use them?" Or just add this modified coffms.inc to your curated build environment and enjoy the benefits - your call.

The prior pattern of library building required putting every function in its own object file and then creating `.LIB` files -- that made development slower and error prone. Today we can put all the versions of the same algorithm and supporting data in one file; and it just works as expected.

I've added a simple example that exercises the COMDAT section folding. A single symbol used by the main program u8_as_hex supports dispatching as well as individual ISA builds -- the main program doesn't need to know how that function is defined and no superfluous code/data is in the executable:
1. in the dispatch case, duplicate data from similar algorithms is discarded.
2. in the specific ISA case, unused algorithms are discarded.

Some parts of the example are demonstrative and reflect a development process that support code reuse, and maximum customization (i.e. don't use these algorithms).

I think this is the wrong approach because it might destroy legacy linker support. So, I'm re-engineering a new COFF format for modern tools and will revert to the distributed coffms.inc -- there is no reason to overwrite it with these changes.

Okay, the new implementation is newcoff.inc - configured to work like any, format MS64 NEWCOFF or format MS NEWCOFF. It supports all the COMDAT section stuff and source level debugging in Visual Studio and x64dbg.

Look at the new hexer example/walkthrough.

Still quite a few debugging features to implement, but the new design makes that easier.

I've refined the verbose line mode to only update on emitted bytes. Debug support in x64dbg is okay - some things lacking on both sides still. Visual Studio support is even more extensive.