Overloaded methods in COM have wrong vtable order

[raphlinus]

Apparently the COM-compatible ABI for overloaded methods is to group overloads together but put them in reverse order. I observed this in my use of DirectComposition APIs, but it seems to be pretty poorly documented. The best I could find is gcc bug 53398.

Note that Microsoft has published guidance discouraging overloads in COM-visible interfaces but seems to be ignoring this more recently. I believe this renders C bindings inoperable, but that's a separate question.

Also note the previous link suggests a naming scheme of MethodName MethodName_2 MethodName_3. I personally prefer this over the current scheme of MN1 MN2, especially for methods that end in a digit, for example IDCompositionArithmeticCompositeEffect::SetCoefficient1. Also note that the 1-based numbering is not consistently applied, for example the overloaded methods in dwrite_3.rs use a MN MN1 MN2 convention.

I'll prepare a patch that applies the MN MN_2 MN_3 convention because I think it's best, but am open to other alternatives. It seems unlikely that we'll be breaking many existing users.