Minor changes to improve compilation speed

[Aeledfyr]

This crate is small and compiles quickly, but it's also used everywhere, so trying to improve the compilation speed is worth it.

This PR has a number of optimizations; each commit is independent, so feel free to cherry-pick and take whichever changes you want. This PR preserves the current MSRV of 1.13.

Changes:

• Add rust-version = "1.13" to the Cargo.toml, to partially document the current MSRV
• Change internal methods that use AsRef<Path> to just take &Path
• Use loops instead of iterator combinators in parsing functions
• Make the debug! macro generate no code when not in use
• Use a Vec instead of a HashMap when counting physical cores; using the HashMap requires compiling a lot more code. (The Vec should also be faster.)

My non-scientific benchmarks of a clean build of the library (libc + num_cpus)

• in release mode: 0.8s -> 0.7s (-13%)
• in debug mode: 0.63s -> 0.60s (-5%)

Measuring the amount of code passed to LLVM, using cargo-llvm-lines:
cargo llvm-lines --lib -p num_cpus (with --release for release builds)

• in release mode: 16325 -> 13039 (-20%)
• in debug mode: 24263 -> 18781 (-22%)

[Aeledfyr]

Improved benchmarks, only compiling num_cpus by directly invoking rustc (with the command given by cargo's --verbose):

• release build: from 364.4 ms ± 7.6 ms to 270.4 ms ± 7.8 ms (-25%)
• debug build: from 70.1 ms ± 3.0 ms to 60.4 ms ± 2.7 ms (-13%)

[Aeledfyr]

It looks like most of the CI failures are due to an updated Rust toolchain:

• Nightly tests fail to compile because of a new warning (and #[deny(warnings)])
• Cross compiling to some architectures fails because of a missing rust-std components

The only test that actually fails is test-cgroups, which fails in the initial (non-cgroups) test, because it expects to be run on a machine with 2 cores, but the CI now runs it on a 4-core machine. I'm not 100% sure that that's what is happening, but it may be worth rerunning CI on the main branch to see if that's the issue.