Cases where non-`local` methods are defined in the interface generated by `GetModule`

I noticed the following while investigating [structured storage](https://learn.microsoft.com/en-us/windows/win32/Stg/structured-storage-start-page) and [monikers](https://learn.microsoft.com/en-us/windows/win32/com/monikers) and verifying with the Python wrapper module for `msvidctl.dll`, which defines those interfaces.

When retrieving the `FUNCDESC` that holds the information of vtbl-mapped methods from `ITypeInfo`, which contains the interface information, there are cases where the method has the [`call_as` IDL attribute](https://learn.microsoft.com/en-us/windows/win32/Midl/call-as) instead of the [`local` IDL attribute](https://learn.microsoft.com/en-us/windows/win32/Midl/local).
The methods defined in the interface of the module generated by `GetModule` are based on the information from these `FUNCDESC`s.

However, the parameters of the methods defined for remote procedure calls with the `call_as` attribute may not match the parameters of the methods defined for local use with the `local` attribute.
As a result, attempting to call these methods from the client side may result in errors.

This issue is different from the one discussed in #474 and resolved by @jonschz in #578 for `ISequentialStream.RemoteRead`, where calling low-level functions with preallocation was the solution.
- As seen in the [IDL file](https://github.com/microsoft/win32metadata/blob/185c3ef016663ab8201878da7efab0a2cff0bcc7/generation/WinSDK/RecompiledIdlHeaders/um/ObjIdlbase.Idl#L448-L460), the methods `RemoteRead` and `Read` had the same parameters, differing only in name.

However, in cases like [`IStorage`](https://learn.microsoft.com/en-us/windows/win32/api/objidl/nn-objidl-istorage)'s [`RemoteOpenStream`](https://github.com/microsoft/win32metadata/blob/185c3ef016663ab8201878da7efab0a2cff0bcc7/generation/WinSDK/RecompiledIdlHeaders/um/ObjIdl.Idl#L720-L727) and [`OpenStream`](https://github.com/microsoft/win32metadata/blob/185c3ef016663ab8201878da7efab0a2cff0bcc7/generation/WinSDK/RecompiledIdlHeaders/um/ObjIdl.Idl#L712-L718), where there are parameter differences, calling low-level functions won't resolve the problem.

Furthermore, since [`IEnumMoniker` has `RemoteNext` defined as `call_as(Next)`](https://github.com/microsoft/win32metadata/blob/185c3ef016663ab8201878da7efab0a2cff0bcc7/generation/WinSDK/RecompiledIdlHeaders/um/ObjIdl.Idl#L330-L342), `RemoteNext` is defined instead of `Next`. This results in the interface not meeting the conditions for defining `__iter__`, `__next__`, and `__getitem__` by the `codegenerator`, making it unusable as an iterator.

To differentiate between `local` and `call_as`, using [`ITypeInfo2`](https://learn.microsoft.com/en-us/windows/win32/api/oaidl/nn-oaidl-itypeinfo2) in `tlbparser` or `codegenerator` might be a possible solution.
However, careful implementation is required to avoid losing backward compatibility or unnecessarily complicating the current `codegenerator` or `tlbparser`.

For individual interfaces, this issue could be resolved by statically defining the interface (and its dependent structures) with the local methods and adding them to `__known_symbols__`.
I think that specific issues should be submitted for each interface or framework.