Related to #51769.

Part of #41479.

What problem does this address?

• Avoid fatal errors on sites using the Fonts API once the Fonts Library is merged.

The Fonts API will be replaced by the Font Face #51769. But its classes, functions, and public and protected methods must be loaded into memory and be non-functional (no code except deprecations).

Once the Fonts Library is merged, sites currently using the Fonts API will break with fatal errors. Why? The Font Face files get loaded instead of the Fonts API (its replacing it).

What is your proposed solution?

To avoid breaking sites using the Fonts API, all of the classes, public methods, and functions need to be loaded into memory. To avoid font workflow conflicts, the code within these methods and functions will be removed and not work (non-functional), and deprecations added to alert folks to not use the Fonts API.

Once Font Face is merged into `trunk, then:

1. Copy all of the files from '/lib/experimental/fonts-api/into/lib/experimental/fonts/bc-layer/`.
2. Remove all private methods.
3. Remove all of code from functions and methods, except for deprecation notices and wp_fonts().
4. Ensure each function and method has a deprecation notice that alerts to stop using the Fonts API.
5. Remove all hooks, such as the hooks that call wp_print_fonts().
6. Load each of the files in /lib/experimental/fonts/bc-layer/ in lib/load.php, adding them after the Font Face files.

IMPORTANT:
In lib/load.php, files in lib/experimental/fonts/ (i.e. Font Face and its BC Layer) will only load into memory when the Font Library is merged into trunk or when loaded in tests.

Else, the Fonts API (in lib/experimental/fonts-api) is loaded into memory.

It's important to keep these separate and only load either the Fonts API (all files in lib/experimental/fonts-api/) OR Font Face (all files in lib/experimental/fonts/). Do not load both lib/experimental/fonts-api/ and lib/experimental/fonts/.