Fix and enforce MSRV by building all features during CI

[BenWiederhake]

This PR:

• downgrades fts-sys and selinux-sys (erroneously upgraded in Bump fts-sys and selinux-sys #6339) to achieve MSRV 1.70.0 again
• enforces MSRV by actually compiling all code during CI.

Note that the latter requires that we split the text step into two steps, because cargo nextest --all-features would also include features such as test_unimplemented and expensive_tests, which would always break.

Fixes #6728.

[BenWiederhake]

• Some of our code uses itertools' chunk_by feature, which is only introduced in 0.13.0
• Any fts-sys version that is old enough to work with rust 1.70.0 depends on itertools < 0.13.0, e.g. 0.12.1
• If we use both itertools 0.12.1 and 0.13.0 at the same time, then a lint complains about that.

I see only these options:

• Raise MSRV to >= 1.77 (ugh!)
• Permit using two different versions of itertools at the same time (ugh!)
• Claim that we still have an MSRV of 1.70 for "most" of the code, but it breaks with --feature chcon (ugh!)

All of these are terrible. @sylvestre How would you like to proceed?

[samueltardieu]

* Raise MSRV to >= 1.77 (ugh!)

What is really the problem with raising the MSRV to 1.77.0? Debian stable uses rust 1.65.0 by default, which is older than 1.70 anyway so people stuck with Debian stable have to use rustup and can probably use 1.77.0 (which is more than 6 months old). Debian testing uses 1.80.1, so this is ok.

Who are the "customers" of coreutils who can use 1.70.0 and cannot use 1.77.0? Is it worth holding back using newer versions of commodity packages such as itertools for them? Can't they work with an earlier version of coreutils? Will they want to use the current daily version anyway if they are not allowed to upgrade their compilers, why could they upgrade their coreutils?

[BenWiederhake]

Feel free to open a PR to do so, but I don't want to make a decision on this.

[samueltardieu]

@sylvestre?