Remove fmt dependency and switch to c++23 standard

[Voldemat]

No description provided.

[dreirund]

Looks like a simplification to me, so I suggest merging.

[BlackMark29A]

There are a lot of considerations that need to go into upgrading the C++ standard to 23, and this PR does not address or argue for any of them.

Upgrading the C++ standard would be a breaking change for any project using libenvpp as a dependency that does not/can not meet that standard. This then leads to the question of how to deal with that, whether to provide backwards compatibility (which would mean maintaining two versions), or whether to abandon anything prior to C++23.

There could be an argument made for upgrading the minimum C++ standard to C++20, and dropping support for C++17, since widespread support of C++20 has happened, but the same cannot be said for C++23 yet.

Additionally, when upgrading to C++23 specifically, but also to C++20, significantly more changes should be made to make use of all the new features available in these standards. In particular libenvpp provides its own expected type modeled after std::expected from C++23, which when upgrading to C++23 should be dropped and replaced by std::expected.

[Voldemat]

Well, I just think it is a question of whatever you ready to accept breaking change or not. I did this pr because I had compilation problems with provided fmt, so fix for me was to remove it completely, as I`m already using c++23 in my projects. Also I don`t think it is necessary to modify code to use all new features of c++23, main point of the pr is to remove dependency on fmt. here is the link to c++23 compiler adoption table: https://en.cppreference.com/w/cpp/compiler_support/23.html. I think it is safe to say that all mainstream compilers support c++23 in their latest versions

[BlackMark29A]

This seems like a XY-problem. Removing fmt completely to fix a compilation error is, in my opinion, not the right approach. It would have been better to report the compilation error and the context in which it happens so that it can be fixed. Obviously there shouldn't be a compilation error at all.

Also of course it's not necessary to use all new features, but when introducing a breaking change anyway, it makes sense to make the most of it.

And the issue is not at all compiler support for C++23, but rather widespread adoption of that standard. If libenvpp was to switch to C++23 that would mean that all projects that depend on libenvpp also have to use C++23 (since this is a very template heavy library that mostly exists in headers), and this just isn't the case yet. There are projects that depend on libenvpp which are not yet C++23, and so could no longer use the latest version.

[Voldemat]

I`m not familiar with c++ in enterprise context, but all projects can easily switch to newer versions of compilers and therefore to new version of standard, no? c++ is backwards compatible after all, I dont understand what is hard in changing one cmake variable or installing newest version of compiler

[BlackMark29A]

While this may be true for small projects and toy examples, this is certainly not the case for any sufficiently large project. You'd be surprised how much can break by just changing the C++ standard, even though C++ tries to keep breaking changes between versions to a minimum, they do still exist and need to be dealt with. So this is not as simple as just changing one cmake variable.