Re-Enable fmt module tests, quarantine failing code

[MathewBensonCode]

• Refactor test/CMakeLists.txt to enable testing for modules

• Refactored tests related to fmt::format_args that now requires lvalue
  references as opposed to direct values.

• Isolate Tests and code in module-test.cpp that is causing the issues but allow the rest
  to run. Isolated Tests and code has been commented out
  These include:

  • testing for the fmt::detail namespace. The MSVC github workflow could
    not differentiate the between the fmt::detail and fmt::v12::detail
  • tests for print and vprint, particularly those requiring stdout
    and stderr. an exception was being thrown
  • Several tests for items that have since been removed from the
    library like fmt::is_char and fmt::localtime as far as I can
    tell

• Some of the tests appear to be duplicates of the other regular library
  tests.

  Should close Enable module test #4698

[MathewBensonCode]

@vitaut, what is the scope of testing that we require for testing the module target?

Do we just want to test the public API or the full API?

The tests for the regular library involve tests for the entire library as they are able to reach into the entire code base.

With the module based library, it brings up the issue of visible and invisible APIs.

In this pull request, Ideally I have just remove the "inner" code(and some outdated code), which is being tested by the regular library anyway, and just test that the expected public functionality works.

I have commented out the bits that would be deleted if we we're to take this approach.

The other approach would be to work out how to work with modules and macro based testing frameworks.

I'm doing some experiments with this, but it may need another pull request as the changes are likely to be drastic, like moving tests into headers, or making the tests part of the module, etc.

[vitaut]

We definitely don't need to test everything. A simple sanity test that exercises a small subset of the API should be sufficient. I would recommend splitting the changes into smaller PRs, e.g. focusing on one compiler (e.g. clang) first.

[vitaut]

That said, we shouldn't delete code from the module test if it is broken with modules. On the contrary - we should keep it as a regression test for the fix. It is OK to conditionally compile it until the fix is available.