dispinterface/custdata typelib conformance

[Puetz Kevin A]

> > Kind of a long series, but with the generated code in tests/typelib.c
> > I found squashing much more made it difficult to keep straight, which
> > presumably would make reviewing it hard too.
> 
> Generally it's better just to send a few patches at a time (5 is a good
> number), in particular just by waiting to send the rest rather than trying to
> squash anything.

Yeah, but if I just withheld the conclusion a reviewer couldn't see the
conformance tests which demonstrate the changes match windows.
Or, in v1, pointed out it didn't on x64 (oops!).

I agree a series this long is not ideal and won't make a habit of it.
It's perfectly fine if the review/merge is taken in smaller chunks, 
and that's why I included a cover letter pointing out 6/13 and 11/13
as reasonable spots to pause/split it at.

The fixes are pretty independent, but the for-loop shape of test_dump_typelib
doesn't lend itself to using todo_wine to suppress individual failures.
And you said failing tests first, followed by subsequent fixes to make
them pass, was not OK because it breaks bisecting (a reasonable objection).

Which added up to a long series fixing multiple gaps in oleaut32/widl
that all had to work before there could be coverage added to test_tlb.idl