`-fprefer-bytecode` broken in presence of CApiFFI

CApiFfi imports are currently implemented via the production of a stub object during desugaring. This is problematic in the case of modules loaded from serialised bytecode with -fprefer-bytecode since desugaring is not run.

For instance, imagine a simple C function:

int say_hello() { return 42; }

and a module with capi import (e.g. used in a TemplateHaskell splice):

{-# LANGUAGE CApiFFI #-}
{-# LANGUAGE ForeignFunctionInterface #-}

module Hello where

import Language.Haskell.TH
import Language.Haskell.TH.Syntax

foreign import capi "hello.h say_hello" say_hello :: IO Int

mkHello :: DecsQ
mkHello = do
  n <- runIO say_hello
  [d| hello :: IO Int
      hello = return $(lift n) |]

if one compiles Hello with -fbytecode-and-object-code and then attempt to splice mkHello in a module compiled with -fprefer-byte-code compilation will fail with a linker error:

/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc -c hello.c
/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc -c -fbyte-code-and-object-code Hello.hs
compilation IS NOT required
/mnt/data/exp/ghc/ghc-landing/_build/stage1/bin/ghc -fprefer-byte-code hello.o Main.hs
[2 of 3] Compiling Main             ( Main.hs, Main.o )
ghc: ^^ Could not load 'ghczuwrapperZC0ZCmainZCHelloZCsayzuhello', dependency unresolved. See top entry above.


<no location info>: error:
    
GHC.ByteCode.Linker: can't find label
During interactive linking, GHCi couldn't find the following symbol:
  ghczuwrapperZC0ZCmainZCHelloZCsayzuhello
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session.  Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please report this as a GHC bug:
  https://www.haskell.org/ghc/reportabug

This was astutely noticed by @phadej .