[Test] Disable flakey cursor info cancellation

The exact cause of this is a mystery to me - each test case should be
finished (and thus any ASTs fully built) before the next runs/we exit.

But one of the recent failures contained a stacktrace:
```
...
20 [ra] 0x0000aaaad9d182f0 llvm::opt::OptTable::internalParseOneArg(llvm::opt::ArgList const&, unsigned int&, std::function<bool (llvm::opt::Option const&)>) const + 127 in SourceKitSwiftLangTests
21 [ra] 0x0000aaaad9d188d0 llvm::opt::OptTable::internalParseArgs(llvm::ArrayRef<char const*>, unsigned int&, unsigned int&, std::function<bool (llvm::opt::Option const&)>) const + 303 in SourceKitSwiftLangTests
22 [ra] 0x0000aaaad9d1877c llvm::opt::OptTable::ParseArgs(llvm::ArrayRef<char const*>, unsigned int&, unsigned int&, llvm::opt::Visibility) const + 47 in SourceKitSwiftLangTests
23 [ra] 0x0000aaaad6fad0d0 getLibcFileMapping[abi:cxx11](swift::ASTContext&, llvm::StringRef, std::optional<llvm::ArrayRef<llvm::StringRef> >, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem> const&, bool) + 311 in SourceKitSwiftLangTests
24 [ra] 0x0000aaaad6fab304 swift::getClangInvocationFileMapping(swift::ASTContext&, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>, bool) + 895 in SourceKitSwiftLangTests
25 [ra] 0x0000aaaad6f4dcac swift::ClangImporter::create(swift::ASTContext&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, swift::DependencyTracker*, swift::DWARFImporterDelegate*, bool) + 587 in SourceKitSwiftLangTests
26 [ra] 0x0000aaaad5ba07ac swift::CompilerInstance::setUpModuleLoaders() + 531 in SourceKitSwiftLangTests
27 [ra] 0x0000aaaad5ba0530 swift::CompilerInstance::setUpASTContextIfNeeded() + 447 in SourceKitSwiftLangTests
28 [ra] 0x0000aaaad5ba269c swift::CompilerInstance::setup(swift::CompilerInvocation const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, llvm::ArrayRef<char const*>) + 231 in SourceKitSwiftLangTests
29 [ra] 0x0000aaaad593d634 void SourceKit::WorkQueue::DispatchData::callAndDelete<(anonymous namespace)::ASTBuildOperation::schedule(SourceKit::WorkQueue)::$_11>(void*) + 2155 in SourceKitSwiftLangTests
30 [ra] 0x0000aaaad597c2fc executeBlock(void*) + 27 in SourceKitSwiftLangTests
31 [ra] 0x0000aaaad597c330 void* llvm::thread::ThreadProxy<std::tuple<void (*)(void*), void*> >(void*) + 27 in SourceKitSwiftLangTests
32 [ra] 0x0000ffffab37595c <unknown> in libc.so.6
```

So the assertion above clearly isn't true - we are definitely still
building an AST on exit here.

Regardless, this test is not worth CI failing as often as it is. Let's
disable it for now while we look into the cause.

Author: bnbarham

unittests/SourceKit/SwiftLang/CursorInfoTest.cpp

@@ -335,8 +335,7 @@ TEST_F(CursorInfoTest, CursorInfoMustWaitDueToken) {
   EXPECT_EQ(strlen("fog"), Info.Length);
 }
 
-TEST_F(CursorInfoTest, DISABLED_CursorInfoMustWaitDueTokenRace) {
-  // Disabled due to a race condition (rdar://88652757)
+TEST_F(CursorInfoTest, CursorInfoMustWaitDueTokenRace) {
   const char *DocName = "test.swift";
   const char *Contents = "let value = foo\n"
                          "let foo = 0\n";
@@ -414,7 +413,9 @@ TEST_F(CursorInfoTest, CursorInfoCancelsPreviousRequest) {
     llvm::report_fatal_error("Did not receive a response for the first request");
 }
 
-TEST_F(CursorInfoTest, CursorInfoCancellation) {
+TEST_F(CursorInfoTest, DISABLED_CursorInfoCancellation) {
+  // Disabled due to a race condition (rdar://88652757)
+
   // TODO: This test case relies on the following snippet being slow to type
   // check so that the first cursor info request takes longer to execute than it
   // takes time to schedule the second request. If that is fixed, we need to