This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do.
This change is still mostly mechanical, although the effects trickled out a bit higher than with other similar patches. I did manually verify that every call-site was either setting nothing at all, or only setting the module field of the SymbolContext.