driver: Add support for building and using bytecode libraries

This patch contains two separate commits.

1. Add the -bytecodelib flag, to produce a bytecode library.
2. Support loading bytecode libraries to satisfy package dependencies which using the interpreter.

Each one builds and passes the testsuite individually.

Add support for building bytecode libraries
    
A bytecode library is a collection of bytecode files (.gbc) and a
library which combines together additional object files.
    
A bytecode library is created by invoking GHC with the `-bytecodelib`
flag.
    
A library can be created from in-memory `ModuleByteCode` linkables or
by passing `.gbc` files as arguments on the command line.
    
Fixes #26298

This commit allows you to use a bytecode library to satisfy a package
dependency when using the interpreter.

If a user enables `-fprefer-byte-code`, then if a package provides a
bytecode library, that will be loaded and used to satisfy the
dependency.

The main change is to separate the relevant parts of the `LoaderState`
into external and home package byte code. Bytecode is loaded into either
the home package or external part (similar to HPT/EPS split), HPT
bytecode can be unloaded. External bytecode is never unloaded.

The unload function has also only been called with an empty list of
"stable linkables" for a long time. It has been modified to directly
implement a complete unloading of the home package bytecode linkables.

At the moment, the bytecode libraries are found in the "library-dirs"
field from the package description. In the future when `Cabal`
implements support for "bytecode-library-dirs" field, we can read the
bytecode libraries from there. No changes to the Cabal submodule are
necessary at the moment.

Four new tests are added in testsuite/tests/cabal, which generate fake
package descriptions and test loading the libraries into GHCi.

Fixes #26298