Fixing linking fmt & improved visitor patterns

[KaruroChori]

Closes #29 and #30

This last commit has regressions in linking which I am not able to fully isolate.
Running in CI might help to figure out what is going on. it did, issue found out, resolution pending.

That being said I will make use of this PR to fix/improve the visitor interface, so that the new print2 serialization is not needing memory allocations for the lambda capture contexts.

[KaruroChori]

It looks like something broke on my system for whatever strange and obscure reason? I get errors like this when replicating the same build of CI.

g++-14  -o utils/vs-xml.decode utils/vs-xml.decode.p/decode.cpp.o -Wl,--as-needed -Wl,--no-undefined '-Wl,-rpath,$ORIGIN/..' -Wl,-rpath-link,/home/migration/Documents/projects/vs.xml/build3/ libvs-xml.so
/usr/bin/ld: utils/vs-xml.decode.p/decode.cpp.o: undefined reference to symbol '_ZN3fmt3v107vformatB5cxx11ENS0_17basic_string_viewIcEENS0_17basic_format_argsINS0_20basic_format_contextINS0_8appenderEcEEEE'
/usr/bin/ld: /lib/x86_64-linux-gnu/libfmt.so.10: error adding symbols: DSO missing from command line

[KaruroChori]

So, the issue was found. In impl.hpp one of the assertions had a std::format converted to VS_XML_NS::format, and I am compiling using fmt in place of the std version.
Which means, the specific template being used will only ever be reserved once at compiletime.
Solutions to this issue are:

• Being explicit on which template versions of format should be generated.
• Link the library to the final executables as well.

This is a huge pain to handle, and makes the build process much more fragile than what I would like. But some solution will be found at some point.