I18N: Set C++ locale and format sizes according to the locale

[ppisar]

Displaying a package size, an installation size, a download speed etc. formats decimal numbers to 1-digit precision after the decimal point (49.5 KiB). However, users expect the number to be formatted according their locale. E.g. in cs_CZ.UTF-8, it is "49,5 KiB".

DNF5 formats these values with fmt::format() which utilizes C++ locale if "L" formatting option is used.

C++ locale (std::locale::global()) and C locale (setlocale(), C++-wrapped as std::setlocale()) are two different things and DNF5 only has set the C locale up to now.

This patch starts setting C++ locale, which also implicitly sets C locale. This patch also modifies
libdnf5::cli::utils::units::format_size_aligned() to use the locale-dependent decimal seperator (available since fmt-8.0.0).

I manually tested dnf5 and dnf5daemon-client and they work for me.

Though there is a risk that the new C++ locale will affect some code uknown to me, like regular expression matching, or thread-specific locales. If the affected code was unfixable, we can resort to saving the desired C++ locale into a dedicated object accessible to format_size_aligned() and pass it explicitly for fmt::format. Thorough testing is welcome.

Related: #1687

[packit-as-a-service]

We were not able to find or create Copr project packit/rpm-software-management-dnf5-1699 specified in the config with the following error:

Packit received HTTP 500 Internal Server Error from Copr Service. Check the Copr status page: https://copr.fedorainfracloud.org/status/stats/, or ask for help in Fedora Build System matrix channel: https://matrix.to/#/#buildsys:fedoraproject.org.

---

Unless the HTTP status code above is >= 500, please check your configuration for:

1. typos in owner and project name (groups need to be prefixed with @)
2. whether the project name doesn't contain not allowed characters (only letters, digits, underscores, dashes and dots must be used)
3. whether the project itself exists (Packit creates projects only in its own namespace)
4. whether Packit is allowed to build in your Copr project
5. whether your Copr project/group is not private

[jrohel]

I wonder how many inputs, outputs and regexes this PR will break.
We already have broken parsing of some configuration values for some locales. Probably from this #1408. And it's because parsing uses functions that depend on the C locale (at least std::stod is used for log_size, bandwidth, minrate, all options using class OptionSeconds and std::stof for throttle).
This PR breaks the parsing of other numeric configuration values for some locales (OptionNumber class uses operator >> for parsing).

I'm considering whether to merge this PR now or first prepare a PR to fix the bugs I mentioned above.

[ppisar]

First we need to fix the parser.

[ppisar]

Some locale bugs in the parser are tracked in #1706.