Putting FMT_API on the class definition propagates it to the base class
detail::buffer<char>'s members. However, MSVC not emit definitions for
inline members unless it sees the symbols as FMT_API when compiling.
This fix removes the FMT_API declaration from the class itself and marks
individual non-inline members as FMT_API to address the issue.
Fixes https://github.com/fmtlib/fmt/issues/4576
* Mark some in-class defined member functions as explicitly inline/constexpr, to avoid missing external symbols when using fmt module with shared build due to modules not defaulting to implicit inline.
* Switch constexpr to inline for context::arg(string_view).
NOTE: Looks as if basic_format_args::get(string_view) could probably be made constexpr instead, but sticking with minimal change approach.
* Work around apparent non-conformance of older MSVC compilers.
* Switch format_int::str() from constexpr to inline to satisfy libstdc++ std::string constexpr limitations.
* Replace usages of macros for constexpr/inline with keywords.
* Fix for locations requiring C++14 constexpr.
* Further minor constexpr tweaks.
* Apply clang format
Some MSVC-specific behavior:
When class fmt::ostream inherits detail::buffer - the last gets implicitly exported when fmt is built as a shared library.
Unless os.h is included, the compiler assumes detail::buffer is not externally exported and instantiates a local copy of it, which causes ODR violation.
With aggregation - there is no extra exporting of detail::buffer symbols.
The documentation for output_file incorrectly says that opening an output file happens with `file::WRONLY | file::CREATE` by default, but this includes `file::TRUNC` is also included since 119f7dc3d.
'os.h' accepts a predefined FMT_USE_FCNTL override so using FMT with e.g. the NXP toolchain for ARM (e.g. for FreeRTOS) does not have a fcntl() call, but the detection routine does not detect this correctly.
