Temporarily disable 'edited_method_body.swift' and 'edited_property_getter.swift' while investigating CI failures

[artemcm]

No description provided.

[artemcm]

@swift-ci smoke test

[shahmishal]

cc: @compnerd

[artemcm]

Module remarks do yield some more info.

<unknown>:0: remark: loaded module '_Concurrency'; source: 't:\1\lib\swift\windows\_Concurrency.swiftmodule\x86_64-unknown-windows-msvc.private.swiftinterface', loaded:
't:\1\lib\swift\windows\_Concurrency.swiftmodule\x86_64-unknown-windows-msvc.swiftmodule'

happens on the first of the two compiles, and then on the second one we get:

<unknown>:0: remark: loaded module '_Concurrency'; source: 't:\1\lib\swift\windows\_Concurrency.swiftmodule\x86_64-unknown-windows-msvc.private.swiftinterface', loaded:
'T:\1\swift-test-results\x86_64-unknown-windows-msvc\clang-module-cache\_Concurrency-1JY50GAN4EIFO.swiftmodule'

I wonder if the timing works out such that some other process/test builds a module into the module cache between these two runs, and, for some reason, we then decide to not use the pre-built adjacent binary module, in favour of the module-cache one.