[5.9][sourcekitd] Allow client to enable use of dispatch barriers for open/edit/close on the message handling queue

[ahoppen]

• Explanation: Previously, we relied on the client to make sure any open/edit/close request has finished executing before sending semantic queries about that updated source file, implicitly relying on clients to provide synchronization guarantees. This enables a mode in which sourcekitd can provide those synchronization guarantees:
  By default, all behavior stays the same. After the client sends a source.request.enable_request_barriers request, sourcekitd will issue all open/edit/close requests as dispatch barriers. This makes sure that all requests after the open/edit/close will only start being handled after the open/edit/close has finished.
• Scope: No functionality change unless the new barrier mode is enabled
• Risk: While changing anything surrounding queues can be considered risky, this should be low-risk since there is no functionality change unless the new barrier behavior is explicitly enabled
• Testing: Ran unit test and SourceKit stress tester, both of which continue to use the code path that doesn’t use barriers
• Issue: rdar://91202327
• Reviewer: @bnbarham and @rintaro on [sourcekitd] Allow client to enable use of dispatch barriers for open/edit/close on the message handling queue #66013

[ahoppen]

@swift-ci Please test