Added protocol to support CVarArg objects that need to be retained

[Molanda]

To fix string formatting using %@ and a String argument, the CVarArg protocol needs to be implemented on String. To do this, String requires an NSString to return a CFString which is what is finally used by the formatting.

However, without an autorelease pool (as is the case with most non-Apple platforms), NSString will get destroyed once out of scope of _cVarArgEncoding.

This pull request adds a new protocol to support retaining such objects without requiring an autorelease pool.

Please see Foundation PR #2821 and this post for more details.

Resolves SR-957.

[millenomi]

This is desirable for source compatibility between Darwin Foundation and corelib Foundation.

[DougGregor]

Since this is affecting public entry points, we either need to add availability for Darwin platforms or we need to make the new entries only available on platforms where there is no Objective-C runtime. I suspect the latter is the better choice?

[millenomi]

@Molanda I would recommend only #ifdefing to platforms without the ObjC runtime.

[Molanda]

Thank you for the comments.

I will make the changes sometime this weekend.

[Molanda]

I have made the recommended changes so the retaining object protocol is only used when the ObjC runtime is not available.

[DougGregor]

@swift-ci please test

[DougGregor]

@lorentey have any opinions on this?

[Molanda]

Just checking in to see if anything additional is needed on this one.

[millenomi]

@DougGregor @lorentey any more feedback? This is highly desired for master.

[lorentey]

Looks good to me!

It would be desirable not to autorelease on Apple platforms, either. To do that, we'd probably want to augment the retainer array with inline space for a couple object references (to prevent allocations in the common case), and I'm 99% sure we'd also want to remove @inlinable from all builder methods. (Exposing the vararg builder's class members in the ABI was a regrettable step.)