Clarify that edits passed to IncrementalParseTransition are concurrent and add function to transform sequential edits to concurrent

[ahoppen]

To clarify that the edits passed to IncrementalParseTransition are applied concurrently, introduce a new ConcurrentEdit type that provides the guarantee and allows translation of sequentially applied edits to the expected concurrent form.

Fixes rdar://72848263

[ahoppen]

@swift-ci Please test

[akyrtzi]

isEditArrayValid() can be made internal now.
Also normalizeEdits() is only useful to be made public for testing purposes, should we have it underscored?

[akyrtzi]

We should:

• Make it clear in documentation comments that the edits are considered concurrent
• Make the initializer accept normalized edits with a precondition to check them (or maybe throw an error, though that would change API/ABI)
• Provide the normalizeEdits() as helper function but have it accept either concurrent or cumulative edits

[ahoppen]

OK, I refactored the PR pretty significantly (although the translation algorithm stayed mostly the same).

IncrementalParseTransition now takes ConcurrentEdits instead of [SourceEdit]. ConcurrentEdits can either be initialized from [SourceEdit] that are already guaranteed to be in concurrent form or from an array of sequentially applied edits, which are then translated to concurrent edits in the expected form. This way, the user of the API always needs to make a deliberate choice which constructor of ConcurrentEdits to invoke and thus shouldn’t make any false assumptions about how the edits are interpreted.

I kept the old initializer, made it call through to ConcurrentEdits.init(concurrent:) and marked it as deprecated so the change isn’t API breaking for now.

[ahoppen]

@swift-ci Please test

[akyrtzi]

This API isn't used much, a search on GitHub only showed the stress-tester, but having a transitional step is goodness.

[akyrtzi]

Typo "guranteed"

[ahoppen]

@swift-ci Please test