Webfonts API Architecture: Remove external access to internal-only functionality

[hellofromtonya]

Part of #41479.

Problem Statement

The current and some ongoing open work expose internal-only functionality through global private functions. Unlike private or protected methods, PHP does not support limiting functions for internal-only usage. Though documented in the function DocBlock as private, these global functions are not truly private, meaning each is publicly exposed.

Why is this problematic?
Anything in the global space is fully accessible internally (within Gutenberg and WordPress Core) and externally (for extenders). Changes can be a backwards-compatibility issue, especially given the API will be a WordPress Core backend API to support block and classic web font needs.

Scope

Explore removing external access to internal-only functionality by removing private global functions and replacing with abstractions.

Benefits / Goals

• eliminate any future backwards-compatibility concerns when changes are needed (including function signatures, renaming, removing, return data or types, and internal workings)
• future flexibility
• reduction of future burden costs

Ways to Accomplish

Some potential ways to accomplish are:

• Abstracting within a class structure to leverage private methods.
• Private containers: group inter-workings to encapsulate within a single global function (e.g. Move webfonts handling to internal only (not accessible) - WP 6.0 Stopgap #40472) for things like filter/action callbacks.

[hellofromtonya]

#50250 resolved architectural issues with 2 global functions. I don't see other opportunities for hiding public access to internal-only functionality. Therefore, I think this issue can be closed.