Add "arch" struct field to repository_os

[fmeum]

This new field provides access to the Java "os.arch" property to
repository rules, which previously had to rely on uname (Unix) or
additional env variables (Windows) to detect the architecture.

This also fixes a small issue in the existing implementation of
repository_ctx.os.name, which should use the root locale when converting
the value of the "os.name" property to lowercase.

Existing sites of manual architecture detection in shipped repository
rules as well as redundant calls to lower() on the value of
repository_ctx.os.name are cleaned up.

Fixes #14685

[Wyverald]

Looks great, thank you! Any more changes planned before you un-draft this?

[fmeum]

@Wyverald The implementation is complete, I'm just not sure whether it does the right thing: As discussed in #14685, os.arch depends on the architecture of the JDK, which may not agree with the architecture of the system it is running on (think Rosetta). With this PR, it would thus be possible to create repository rules that behave differently depending on the architecture of the Bazel binary. Do you think that's fine to ignore as an edge case?

[Wyverald]

Ah, I see. It seems fine to me to use os.arch since we are running in a JVM after all, but let's wait for consensus on the other thread. cc @meteorcloudy

[meteorcloudy]

Nice, thanks for adding this!

@katre With this change, we probably can starlarkify https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/repository/LocalConfigPlatformFunction.java ? (Although the exact logic of getting OS and CPU is a bit different that just checking os.name and os.arch)

[fmeum]

@meteorcloudy Marked as ready, thanks for the review.

[katre]

@meteorcloudy Yes, we could possibly use this to rewrite LocalConfigPlatformFunction, although it's at such a low level in the hierarchy of dependencies I'd be very worried about correctness and performance.