runtime: swap the order of raceacquire() and racerelease()

In chansend() and chanrecv() of chan.go, the order of calls to
raceacquire() and racerelease() was swapped, which meant that the
code was not following the memory model "by the letter of the law."
Similar for bufrecv and bufsend in select.go

The memory model says:

- A send happens before the corresponding receive completes, and
- the kth receive on a channel with capacity C happens before the
k+C send on that channel completes.

The operative word here is "completes."  For example, a sender obtains
happens-before information on completion of the send-operation, which
means, after the sender has deposited its message onto the channel.
Similarly for receives.

If the order of raceacquire() and racerelease() is incorrect, the race
detector may fail to report some race conditions.

The fix is minimal from the point of view of Go.  The fix does, however,
rely on a new function added to TSan:

https://reviews.llvm.org/D76322

This commit only affects execution when race detection is enabled.

Added two tests into `runtime/race/output_test.go`:

- `chanmm` tests for the issue addressed by this patch
- `mutex` is a test for inverted semaphores, which must not be broken
  by this (or any other) patch

Fixes #37355

Change-Id: I5e886879ead2bd456a4b7dd1d17253641b767f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/220419


Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>