Bypass font path prefix check in ResourcesCompat::loadFont

[DSteve595]

This changes the way in which ResourcesCompatVisitorFactory works around the annoying font prefix check in ResourcesCompat::loadFont, which checks that font paths begin with "res/". The workaround introduced in #1586 works when the font's file path in the project contains "res/", but that's not guaranteed (e.g. alternate source directories, generated sources).
Given that I don't think this resource path check gives any value to Paparazzi tests, this fixes those edge cases by bypassing the check completely, assuming startsWith returns true. Still hacky, but it already was.

Fixes #1794

[geoff-powell]

nit: this looks good but might be better in a separate test project. Not a blocker for this PR.

[geoff-powell]

this change makes sense instead of an arbitrary contains method, skipping the whole startsWith method eval.
Thanks for the contribution!!

[jrodbx]

The workaround introduced in #1586

FWIW, that workaround was adopted from Android Studio's own implementation here:
https://cs.android.com/android-studio/platform/tools/adt/idea/+/mirror-goog-studio-main:rendering/src/com/android/tools/rendering/classloading/ResourcesCompatTransform.kt;l=64?q=ResourcesCompat

, but that's not guaranteed (e.g. alternate source directories, generated sources).

generated sources are handled in a different manner. I'm curious: what's the use case for having alternate resource directories @DSteve595? And more importantly, does that mean that Android Studio's Compose Previews are broken for you given its reliance on the above linked implementation?

[geoff-powell]

generated sources are handled in a different manner. I'm curious: what's the use case for having alternate resource directories @DSteve595? And more importantly, does that mean that Android Studio's Compose Previews are broken for you given its reliance on the above linked implementation?

yes I had the same thoughts. As this unblocks your issue, I have the same hesitancy to mimic AS vs our own differing solution.

[DSteve595]

Our use case is basically just multiplatform, where we're using Android's directory structure but happened to called the directory "resources" rather than "res". It's something that's easily changed on our part (or easily worked around by copying the resources into a generated dir named "res"). But my thinking with this was: if it's a valid resource that an Android app can read, then Paparazzi should be able to read it too.
Previews are broken in Android Studio too, and I didn't realize it was due to this. I consider it an Android Studio bug (well, really a ResourcesCompat bug, but one that affects Studio), for the same reason.
Feel free to revert if matching Studio's behavior seems preferable.