Add dagger to third_party in preparation for an upcoming conversion
of the junit test runner from Guice to Dagger.

Part #1: without the BUILD file (needs a separate change)

Change-Id: Idae2182c491e01d2f0b5e852a5314e65624592c6

*** Reason for rollback ***

Breaks builds internally.

*** Original change description ***

Move Apple toolchain setup to apple_support

This moves the CC toolchain for building Apple platforms besides macOS to the apple_support repo bazelbuild/apple_support#113

The default unix toolchain is now used if someone wants to build for macOS without the apple_support toolchain, but it doesn't handle as many platform specific features as the previous toolchain.

Fixes #1...

***

PiperOrigin-RevId: 516486823
Change-Id: If9b2542699cf8704e0a511e684d8519468ddd937

*** Reason for rollback ***

Breaks builds internally.

*** Original change description ***

Move Apple toolchain setup to apple_support

This moves the CC toolchain for building Apple platforms besides macOS to the apple_support repo bazelbuild/apple_support#113

The default unix toolchain is now used if someone wants to build for macOS without the apple_support toolchain, but it doesn't handle as many platform specific features as the previous toolchain.

Fixes bazelbuild#1...

***

PiperOrigin-RevId: 516486823
Change-Id: If9b2542699cf8704e0a511e684d8519468ddd937

… order.

1. `TestAttempt` events would wait for the `TargetCompleteEvent` to be posted before being posted.

2. There was an implicit requirement for the `TestAttempt` events to be posted in a specific order.

3. This didn't break in the noskymeld case because we fulfilled this ordering by using the order of performing the attempts themselves. The sequence would look like:
    + post `TargetCompleteEvent`
    -> perform attempt #1
    -> post `TestAttempt` #1
    -> perform attempt #2
    -> post `TestAttempt` #2

4. With skymeld, however, it could happen like this:

    + defer `TargetCompleteEvent` to wait for `CoverageActionFinishedEvent`
    + perform attempt #1 -> defer posting `TestAttempt` #1 & wait for `TargetCompleteEvent`
    + perform attempt #2 -> defer posting `TestAttempt` #2 & wait for `TargetCompleteEvent`
    + `CoverageActionFinishedEvent` -> release & post `TargetCompleteEvent`
    + `TargetCompleteEvent` -> release & post `TestAttempt` #2
    + `TargetCompleteEvent` -> release & post `TestAttempt` #1

Due to (2), the undefined ordering in (4) would cause an issue.

This CL fixes that by ensuring a FIFO ordering of the deferred events.

PiperOrigin-RevId: 572165337
Change-Id: Iac4d023d946865b8b81f15b119417192dc4b5c53

Previously, child events could be published before their parent events during a race in the `BuildEventStreamer#post` method. This method was not synchronized around delivering events to the `BuildEventTransport` objects, so it was possible for this race to occur:

Thread #1 | Thread #2
----------|-----------
make parent event |   
post parent event |   
  | make child event
  | post child event
  | deliver child event
deliver parent event |  

TESTED: extensive benchmarking rules out increase in wall time or heap high-water-mark.

RELNOTES: BEP events will now be written respecting parent-child ordering constraints.
PiperOrigin-RevId: 884592559
Change-Id: Iaaac7f48b849c146632fbc10ce3c2e4e1fa6af07