Reserve CPUs for GoStdlib and hold it to them

A single GoStdlib action runs "go install", which compiles the standard
library with one compiler per core. Bazel estimates one CPU for it, so it
schedules as many GoStdlib actions at once as the machine has cores, each
of which then tries to use the whole machine.

Declare a resource_set of four CPUs and pin GOMAXPROCS to the same number
so the reservation is accurate rather than an estimate Bazel cannot
enforce.

Measured on a 16 core machine building 8 stdlib configurations, best of
two interleaved passes:

    reservation             wall    peak RSS
    none (Bazel default)   26.4s     2085 MB
    2 CPUs                 28.7s     1343 MB
    4 CPUs                 27.3s      984 MB
    8 CPUs                 32.8s      647 MB
    16 CPUs                50.2s      678 MB

Four keeps the wall time of the default while halving peak memory. The
default is close on this machine but scales the wrong way: it puts no
bound on how many stdlib builds run at once, so both the concurrency and
the memory grow with the core count of the executor.

This changes the GoStdlib action key, so standard libraries rebuild once.