Follow up to #6886

Why is this the best possible solution? Were any other approaches considered?

This way of loading web pages was having problems with forum (Discourse) links as seen in #6879. My guess is that the double fallback it was there for (from Custom Tabs to external browser to WebView) is from a time when Custom Tabs were Chrome only (they were introduced almost 10 years ago to the day). That's no longer the case and most browsers on Android now support Custom Tabs, and it's very unlikely that a device would not have a browser installed.

We'd also ended up using WebViewActivity directly in some parts of the app, but I think that's a mistake.

Additionally, after refactoring how the web page preloading works, I realized that it was hardly being used, so I removed it. From the commit message:

This only worked with Chrome and was really only properly being used on the About screen. It doesn't feel worth maintaining code with that level of complexity for that minimal benefit.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

There should be no noticeable changes other than for devices that don't have a browser installed - they will now see a Toast error when opening a web page from the app (like the links in About).

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines