Clarify behavior around "send reports" with active delivery attempts

Right now, the specification says nothing about what happens if the "Send reports" algorithm is called while (a) previous instance(s) of the "Attempt to deliver reports to endpoint" algorithm is/are still running.

If an implementor handles this by requiring all delivery attempts to finish before doing "Send reports" again, then a slow or unreachable endpoint for one origin can delay delivery to endpoints for other origins.

If an implementor handles this by allowing "Send reports" to run while delivery attempts are still in progress, then it may end up doing this: Origin A causes a report. User-agent sends reports. A delivery attempt starts to origin A's endpoint. Origin B causes a report. User-agent sends reports. The delivery attempt to origin A's endpoint is still pending, so those reports are still in the queue, so delivery attempts start to both origin A's and origin B's endpoints. Origin A ends up getting two copies of the report if the first attempt succeeded too.

Here are a few possible fixes:

1. Require implementations to postpone "send reports" until there are no delivery attempts in progress. This is not ideal, as noted above, but will not result in duplicates.
2. Require implementations to keep a set of (origin, group) tuples that are included in active delivery attempts, and exclude reports with those tuples from new calls to "send reports". This allows parallelism between origins and between groups within an origin, but strictly serializes reports to a single site.
3. Set a "delivery attempt in progress" flag on the actual reports as the delivery attempt starts, set it when including the report in a delivery attempt, and clear it if the attempt fails. This is more complex, but allows two delivery attempts for the same (origin, group) to run in parallel if new reports arrive while the old ones are still being delivered.