Implement Erlang Quickcheck Race condition property-based testing

[StevenACoffman]

While Go's built-in data race detector remains a best-in-industry tool, by design Go's race detector has a mutex blind spot:

Modeling locks as synchronization points causes blind spots, but this was likely a design decision made to ensure high performance and no false positives

As a result, adding property-based race detection, specifically for finding mutex lock race conditions, would be quite useful to add to rapid.

In an Erlang quickcheck paper there are details on how they are able to use parallel property-based testing to find race conditions, and it would be nice if these mechanisms were supported by Rapid.

[flyingmutant]

Do you have any concrete design ideas as to how this might look to be ergonomic and useful?

The way I see it is that as soon as we start talking concurrency, we need deep integration with the Go scheduler, runtime and synchronization primitives, which is not possible to do from a library.