djgpp compatibility

[jwt27]

These two patches make the library compile on djgpp (using gcc 10.3.0). Everything seems to work, although the test cases don't compile, due to excessive usage of std::wstring. They would probably work if you replaced all those, but I don't really see the purpose in doing that.

I've wanted to use fmtlib for a long time, but making it compatible with djgpp always seemed like a lot of work, so I kept putting it off. I thought everything related to wide character strings would have to be #ifdef'd out.
Turns out the only problem is std::wstring, which is only ever used on two lines. :)

[jwt27]

This fixes #1077.

[vitaut]

Thanks for the PR but missing wstring and wostream is non-conformant and we shouldn't be providing workarounds for this. You can define those aliases in your code before including {fmt}.

[jwt27]

Could those typedefs be provided by fmt (as is the case for wstring_view)? Technically adding anything in namespace std is undefined behavior, according to the standard.

edit: also it's not possible to build a static library if wstring/wostream are not available in the std headers.

[vitaut]

Could those typedefs be provided by fmt (as is the case for wstring_view)?

This is essentially the same workaround that I don't think is worth doing considering a very niche nonconformant target. You might want reporting this to djgpp maintainers if there are any and/or patching {fmt} locally.

[jwt27]

It's been reported there before and nothing was ever done. I think it'll be significantly easier to keep fmt compatible with djgpp rather than the other way around - a whole bunch of wchar_t string functions would need to be implemented in libc, that likely no one will ever use, only to gain two typedefs in libstdc++.