Handle module re-exports correctly when inferring fixity of operators

[mrkkrp]

After #994 we are now more precise about fixities, but this comes with a problem that some users may perceive as a regression, and they would be right. Now that we infer fixities based on import sections, we need to be precise about what operators are imported and from where. #994 largely handles that decently enough, except for one important case—module re-exports. The Hoogle database that we use to scrap operator/fixity declaration provides zero information about module re-exports, which means that when someone imports e.g. Control.Lens, they can't expect the same results as when they import Control.Lens.Operators. I think this is serious enough to delay the release of 0.7.0.0 for now.

[mrkkrp]

Perhaps we could switch to using Hackage index and parse it with the GHC parser. What's worse there is also the possibility of arbitrary operator re-export which would mean that we need to take into account import sections of the files we are sourcing our fixity information from.