ghc -M fails to correctly account for indirect SOURCE imports
Consider a program such as:
```haskell
--- in the unit1 unit
-- Foo.hs-boot
module Foo where
foo :: String
-- Foo.hs
module Foo where
foo :: String
foo = "hi"
-- ... additional cyclic bindings here which make `Foo.hs-boot` necessary
-- Bar.hs
module Bar where
import {-# SOURCE #-} Foo
bar = ... foo ...
--- in the unit2 unit
-- Baz.hs
module Baz where
import Bar
baz = ... bar ...
```
Imagine running `ghc -M` on `Baz.hs`. It will contain something like the following:
```makefile
Baz.o : Baz.hs Bar.o
Bar.o : Bar.hs Foo.o-boot
Foo.o : Foo.hs
Foo.o-boot : Foo.hs-boot
```
This seems perfectly reasonable: it captures the dependency structure of the user's program.
However, if we consider what happens during one-shot compilation, we will see that it isn't quite right. Specifically, imagine that `baz` get an unfolding, which will naturally contain a reference to `Bar.bar` (which was `SOURCE` imported). When we compile `Baz` GHC will see that:
1. we need a declaration for `Foo.foo` in order to unfold `Bar.bar`
2. the user hasn't imported `Bar` directly; this means that `GHC.Iface.Load.importDecl` will call `loadInterface` with `ImportBySystem`
3. `GHC.Iface.Load.loadInterface` calls `GHC.Iface.Load.wantHiBootFile` to determine what it should load
4. `wantHiBootFile` sees that `Foo` is not in the unit currently being compiled. Consequently, it responds with `NotBoot`
5. GHC attempts to load `Foo.hi` instead of `Foo.hi-boot` as the `ghc -M` output claims
issue