internal/race: add the package

[dvyukov]

We have a bunch of race-related copy-paste in sync, sync/atomic, net, syscall, runtime.
Moreover, any race-related functionality requires 2 files -- race.go and norace.go -- as
race functions are not provided by runtime in non-race build.

We can create internal/race package and move things like IsEnabled, Acquire, Release to
it. It will remove the copy-paste and all the additional files from other packages.

Additionally then we will be able to easily exclude or tune tests in race mode using
race.IsEnabled. E.g. now we have the cpuprof test that constantly flakes on
freebsd-amd64-race.

[minux]

Comment 1:

i think race.IsEnabled is rejected? if we don't want to
add it to runtime/race, then we shouldn't add it to
internal/race.
why profiling tests flake with race detector enabled?
they are supposed to be independent.

[dvyukov]

Comment 2:

Regarding race.IsEnabled, we don't want to give it to Go users, because it's too easy to
abuse it and just suppress all races. Nothing was said regarding internal-only
race.IsEnabled, we can use it judiciously.
> why profiling tests flake with race detector enabled? they are supposed to be
independent.
The test is bad, it assumes that most of the CPU cycles will be in a particular
function. While race and cpuprof are independent, the test assumption breaks under race
detector. I guess most samples go into race runtime.

[minux]

Comment 3:

if it is too easy to abuse, we shouldn't use
it in std packages' tests, because that will
set the wrong example.
we probably can fix the test by not triggering
any race detector hooks.
another strange thing is that the test mostly
flake on freebsd, but not linux/darwin/windows.

[dvyukov]

Comment 4:

> we probably can fix the test by not triggering any race detector hooks.
How can we do it? It means not calling functions and not accessing any heap/global
memory.
> another strange thing is that the test mostly flake on freebsd, but not
linux/darwin/windows.
This can be due to the way I built the runtime. I did not manage to build a fresh
gcc/clang on freebsd, so I used some old default one. So the runtime can be slower on
freebsd.

[minux]

Comment 5:

call one function that has a tight loop that only
modifying local variables? and at the end assign
the local variable to a global/or return it.
all we want is burning CPU cycles.
not being able to call functions might be a problem,
but i expect the compiler to not intrument a func
if it doesn't trigger any hooks.