Issue Description:

The current Swift implementation has 3 types of calling-convention mismatch in runtime, stdlib, and code emitted by the compiler.

These violations are one of the blockers of porting to WebAssembly because swiftcc and C-cc are not compatible on WebAssembly.
In our SwiftWasm fork, we applied a hacky patch to use the same calling convention for each function. However, it may break ABI on Darwin, so I want to ask compiler folks before submitting patches to the upstream.

The violations can be categorized into 4 types:

1. Defined as a C-cc in runtime but published as a Swift-cc public API in stdlib.

For example, `swift_retainCount` is declared and defined in runtime without explicit cc, so it's defined as a C-cc function. But it's published as a Swift-cc public API here in stdlib.
This means some external users can call the function assuming Swift-cc, but the actual implementation in runtime uses C-cc.

• The decl of the function in runtime:

  swift/stdlib/public/SwiftShims/HeapObject.h

  Lines 89 to 90 in 6e35487

  	SWIFT_RUNTIME_STDLIB_API
  	__swift_size_t swift_retainCount(HeapObject *obj);

• The definition in runtime:

  swift/stdlib/public/runtime/HeapObject.cpp

  Lines 442 to 446 in 6e35487

  	size_t swift::swift_retainCount(HeapObject *object) {
  	if (isValidPointerForNativeRetain(object))
  	return object->refCounts.getCount();
  	return 0;
  	}

• The decl of the public API in stdlib:

  swift/stdlib/public/core/DebuggerSupport.swift

  Lines 268 to 269 in 6e35487

  	@_silgen_name("swift_retainCount")
  	public func _getRetainCount(_ Value: AnyObject) -> UInt

The other violating functions in the same way are:

• swift_retainCount, swift_unownedRetainCount, swift_weakRetainCount, _swift_getObjectRuntimeFunctionCounters, _swift_getGlobalRuntimeFunctionCounters, and other RuntimeInvocationsTracking things

2. Emitted as a C-cc from user code, but called as a Swift-cc by stdlib indirectly.

For example, `keypath_get_arg_layout` are emitted as a C-cc function by the compiler, but it's called as a Swift-cc function in the stdlib.

• Compiler emits the function here:

  swift/lib/IRGen/GenKeyPath.cpp

  Lines 281 to 283 in 6e35487

  	auto layoutFn = llvm::Function::Create(fnTy,
  	llvm::GlobalValue::PrivateLinkage, "keypath_get_arg_layout", IGM.getModule());
  	layoutFn->setAttributes(IGM.constructInitialAttributes());

• stdlib calls the function here:

  swift/stdlib/public/core/KeyPath.swift

  Lines 863 to 864 in 6e35487

  	internal typealias KeyPathComputedArgumentLayoutFn = @convention(thin)
  	(_ patternArguments: UnsafeRawPointer?) -> (size: Int, alignmentMask: Int)

Other same cases:

• keypath_get_arg_layout, keypath_destroy, keypath_copy, keypath_arg_init

3. Defined as a C-cc in runtime, but called as a Swift-cc in stdlib

For example, `_isClassType` is mainly called by compiler-emitted code and defined as a C-cc function. But it's also called by stdlib.
The call-site of stdlib uses @_silgen_name to link the function, so it's called through swiftcc.
Fortunately, the API is not exposed from Swift stdlib, so no external user calls it as a Swift-cc.

4. Defined as a C-cc in runtime, but called as a Swift-cc by test binary

`swift_demangle` is defined as a C-cc function in runtime, but called as a Swift-cc function from test case.