`VaList<'_>` does not carry its ABI in its type

Consider the following code that will be valid with extended_varargs_abi_support and c_variadic:

unsafe extern "sysv64" {
    fn nix_valist(vl: VaList<'_>);
}
unsafe extern "win64" {
    fn win_valist(vl: VaList<'_>);
}

For VaList<'_>, part of the c_variadic feature, the type does not contain the ABI it is used with. However, if we want to support defining functions with ..., that use VaList<'_> internally, for every ABI that we would accept with declarations of functions that accept ..., like so:

unsafe extern "sysv64" fn nix_valist(vl: VaList<'_>) {
    todo!()
}
unsafe extern "win64" fn win_valist(vl: VaList<'_>) {
    todo!()
}

then we have two problems:

1. We no longer can expand to the same type, as we currently assume a target can only have one VaList implementation, but in actuality it can have an implementation for each ABI it supports!
2. The VaList that we construct can now be passed to a function like vsnprintf (or the previous nix_valist and win_valist) which accepts the VaList as a parameter. Because VaList does not include the ABI it is constructed with in its type, it is valid to pass it to a function that will assume it uses a different varargs ABI. This can cause incorrect behavior in programs that otherwise take sensible precautions with using variable arguments, like using other data to transfer argument counts and types.

While this is not yet decided as behavior we wish to support, and the relevant functions of VaList are currently unsafe, it may be wise to consider embedding the ABI in VaList to address these problems. The goal would be to have something equivalent to VaList<'_, extern "sysv64">.

@rustbot label: +F-c_variadic +T-lang +T-libs-api

Start by reviewing the VaList and c_variadic behavior described here, including the sysv64 and win64 extern declarations and definitions. Determine whether VaList should encode its ABI, then assess the effects on construction and passing values across ABI-specific functions; done means a decided, consistent design for the currently undecided behavior.