Change type metadata accessors to support incomplete metadata

[rjmccall]

This includes global generic and non-generic global access functions, protocol associated type access functions, swift_getGenericMetadata, and generic type completion functions.

The main part of this change is that the functions now need to take a MetadataRequest and return a MetadataResponse, which is capable of expressing that the request can fail. The state of the returned
metadata is reported as an second, independent return value; this allows the caller to easily check the possibility of failure without having to mask it out from the returned metadata pointer, as well as allowing it to be easily ignored.

Also, change metadata access functions to use swiftcc to ensure that this return value is indeed returned in two separate registers.

Also, change protocol associated conformance access functions to use swiftcc. This isn't really related, but for some reason it snuck in. Since it's clearly the right thing to do, and since I really didn't want to retroactively tease that back out from all the rest of the test changes, I've left it in.

Also, change generic metadata access functions to either pass all the generic arguments directly or pass them all indirectly. I don't know how we ended up with the hybrid approach. I needed to change all the code-generation and calls here anyway in order to pass the request parameter, and I figured I might as well change the ABI to something sensible.

[rjmccall]

@swift-ci Please test and merge.

[slavapestov]

The hybrid approach you describe allows us to dynamically construct type metadata. If you don’t know the number of generic arguments that are required, you only have to handle a fixed number of cases before passing them indirectly.

[rjmccall]

@slavapestov I think I wasn't very clear about what I've done there.

It used to be that all the metadata access functions took all their arguments directly, like foo(a,b,c) or foo(a,b,c,d,e,f,g,h). This doesn't support calls from runtime code that's agnostic about argument count, at least not without major complexity.

The hybrid approach is that we're capping the number of direct arguments and passing the rest indirectly, so that we do foo(a,b,c) but foo(a,b,c,&{d,e,f,g,h}). Except that, to make getting a complete buffer more efficient, it's actually foo(a,b,c,&{null,null,null,d,e,f,g,h}).

My change is that, when we cross the cap, we just pass everything indirectly. So it's either foo(a,b,c) or foo(&{a,b,c,d,e,f,g,h}).

[rjmccall]

So it's still a hybrid approach in many senses, and it still supports reflective calls from the runtime. It's just that, in any particular case, the data is not passed in a hybrid way: it's either all direct (if it fits under the cap) or all indirect.

[slavapestov]

@rjmccall That makes sense, thanks.

[rjmccall]

@swift-ci Please smoke test and merge.

[rjmccall]

@swift-ci Please test and merge.

[rjmccall]

@swift-ci Please test.

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 373cbc710d02f9c4bd09658cf9b08a9b3822c9e4

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 373cbc710d02f9c4bd09658cf9b08a9b3822c9e4

[rjmccall]

@swift-ci Please test.

[rjmccall]

@swift-ci Please test.