Stop FileAccess::fix_path from emitting errors for invalid UIDs

[mihe]

Fixes #101962.

This is mostly a quick hack to prompt a discussion about a more proper fix, and maybe serve as a hold-over, but...

This adds a ResourceUID::has_id check to FileAccess::fix_path, before it tries to call ResourceUID::text_to_id, and instead just clears the output string if it's not a known UID, same as what this error check is already doing inadvertently by returning an empty String when it can't find the UID:

godot/core/io/resource_uid.cpp

Line 199 in 51b0379

ERR_FAIL_COND_V_MSG(!cache, String(), vformat("Unrecognized UID: \"%s\".", id_to_text(p_id)));

Without this, you could otherwise pass perfectly reasonable (or not) but non-existent uid:// paths to FileAccess::fix_path and it would emit the above mentioned error about Unrecognized UID, which is exactly what happens in places like the LSP server, where it runs every string literal in the GDScript file through FileAccess::file_exists, which in turn calls FileAccess::fix_path, as seen here:

godot/modules/gdscript/language_server/gdscript_extend_parser.cpp

Lines 207 to 214 in 51b0379

	} else if (token.type == GDScriptTokenizer::Token::LITERAL) {
	const Variant &const_val = token.literal;
	if (const_val.get_type() == Variant::STRING) {
	String scr_path = const_val;
	if (scr_path.is_relative_path()) {
	scr_path = get_path().get_base_dir().path_join(scr_path).simplify_path();
	}
	bool exists = fs->file_exists(scr_path);

I feel like the proper fix is to change FileAccess::fix_path to instead return a bool, to indicate a failure to fix/resolve the path, like when trying to fix/resolve a non-existent UID, but since that would/should require changing quite a lot of call sites I settled for this for now.

The fact that the LSP server is running every GDScript string literal through FileAccess::file_exists is maybe a bit questionable as well, but that seems like more of a performance concern than anything else. FileAccess::file_exists should not throw errors on non-existent UIDs.

[akien-mga]

CC @HolonProduction as this seems LSP related.

[HolonProduction]

CC @HolonProduction as this seems LSP related.

The fact that the LSP runs every string through this, could probably be improved given that we have more fine grained knowledge about were a path is expected in the completion context, but it would require an architecture change to have this info available outside of completion.

Even if we'd do that, we'd still need a way to resolve the path, which fails silently, since even if a path is expected there could be a user error. So having this fail silently (or providing a silent alternative) seems necessary to me. Can't say anything about this specific implementation though.

Also a learning from the current situation of Variant::get and typed dictionaries: if we make this fail silently, please add a documentation comment to make this contract explicit! Otherwise we'll just get regressions in the future because this behavior changes.

[akien-mga]

Thanks!