MSVC always places the implicit sret parameter after the implicit this
parameter of instance methods. We used to handle this for
x86_thiscallcc by allocating the sret parameter on the stack and leaving
the this pointer in ecx, but that doesn't handle alternative calling
conventions like cdecl, stdcall, fastcall, or the win64 convention.
Instead, change the verifier to allow sret on the second parameter.
This also requires changing the X86 backend to return the argument with
the sret parameter, instead of assuming that the sret parameter comes
first.
Why the loop? If the rest of the code assumes that it is the first or second, it seems better to check only those too, or at least assert that I is 0 or 1.