This fixes the remaining issues from #27461:

When registering a store URI or filename via SSL_CTX_set_default_verify_store(), X509_STORE_load_store{,_ex}(), or X509_LOOKUP_add_store{,_ex}(), which are used for the -CAstore etc. options of several apps:

• At first (e.g., during app startup) the URI or filename is just registered but on actively used. So far, in contrast to the plain file and directory cases, no feedback is given the caller/user in case anything is wrong with the filename/URI.
• When the URI or filename is actually used later to retrieve trust anchor certs, all errors about the URI and its contents get lost.
  There is just the very indirect feedback that not issuer cert could be found, but this is very blurry because this can also be due to many other reasons apart from an error related to the filename/URI.

The fix adds the missing check to by_store_ctrl_ex() for the case that the URI may be interpreted as a local file (path) name, i.e., if there is no scheme or the scheme is file:.
This motivated factoring out a new slightly generalized, corrected, and simplified function OSSL_file_stat() from file_store.c:file_open() and e_loader_attic.c:file_open_ex()

Fix the parsing of URI schemes in OSSL_parse_url(), OSSL_STORE_open_ex(), and ossl_store_register_loader_int(),
factoring out a new internal macro OSSL_SKIP_SCHEME().
So far, the check were too weak, allowing invalid chars and/or an empty scheme.

This caught an invalid scheme name in test/fake_rsa, which is now renamed to 'fake-rsa'.

Fix the documentation of the mentioned function and CLI option parameters,
for which so far it was not mentioned that they support not only URIs but also plain file (path) names,
and partly not mentioned that certs in those stores are loaded only on demand.