GLResolver: fall back to app-managed EGL/GLES when a user resolver is set

[keeper-of-memes]

Problem

On platforms where the current GL context cannot be probed via the platform's native APIs, GLResolver::Initialize() fails hard even when the embedding application has explicitly supplied a resolver via projectm_create_with_opengl_load_proc(). Concrete case: ANGLE on tvOS/iOS. The app owns an EGL context backed by Metal, and there is no system EGL/GLX/WGL for the probe to query, so projectM refuses to initialise even though every GL entry point is resolvable through the app's proc loader.

Change

When the context probe fails AND a user resolver is present, assume an app-managed EGL/GLES context and continue (logged at info level). The app has taken responsibility for providing GL entry points, so an unprobeable context is expected there rather than an error.

Behaviour without a user resolver is unchanged (hard error, as before).

Notes for reviewers

• ~14 lines, single hunk in GLResolver.cpp.
• This is the change that makes libprojectM initialise under ANGLE-on-Metal (tvOS/iOS); it should equally help other embedded/sandboxed environments where the app owns the context.
• Builds clean on macOS (Release), unit tests pass. Running in production in a tvOS app (ANGLE, ES 3.0 on Metal).

[keeper-of-memes]

Additional field evidence: this fallback is now validated in production on two hardware generations — Apple TV 4K 3rd gen (A15) and Apple TV HD (A8), both running libprojectM through ANGLE-Metal with an app-managed EGL context. Same behaviour on both: without the fallback, initialisation fails at the context probe despite a fully functional user resolver; with it, everything downstream works (the A8 additionally needs the ES-version gate relaxed, tracked separately in #1004 discussion).