This pull request introduces the ConcurrentValue protocol, which
describes types for which it is safe to use different copies of a value
concurrently. Value-semantic types, immutable types, and types that
have internal synchronization can all conform to ConcurrentValue.

A value of a non-ConcurrentValue type cannot be transferred
into a separate isolation domain. For example, they cannot be used
in a call to an actor-isolated function on a different actor. Similarly,
a local variable of non-ConcurrentValue type cannot be captured
in a closure that executes concurrently with the function in which
the local variable was declared. The actor-isolation and capture
checking rules have been adjusted accordingly.

Structural types are treated as conforming to ConcurrentValue in
certain cases, although we don't form proper conformances just yet:

• Metatypes always conform to ConcurrentValue.
• @concurrent function types conform to ConcurrentValue;
  their parameter and result types must also conform to ConcurrentValue
• Tuples conform to ConcurrentValue if all element types conform to
  ConcurrentValue.

Nominal types can declare conformance to ConcurrentValue explicitly.
That conformance is checked to ensure that none of the state of the
type lacks a conformance to ConcurrentValue:

• For structs, check that each stored property conforms to ConcurrentValue
• For enums, check that each associated value conforms to ConcurrentValue
• For classes, check that each stored property is immutable and conforms
  to ConcurrentValue

Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.

This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that inherits ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.

Roll out ConcurrentValue conformances throughout the standard library,
which both makes a lot of code "just work" and also provides out the
effectiveness of the checking and the model.

The checking for ConcurrentValue conformances is always enabled, since
there is no code using this protocol. However, all of the other diagnostics
related to ConcurrentValue checking are staged in as warnings behind a
flag -Xfrontend -enable-experimental-concurrent-value-checking.