### Godot version

4.0.dev.d1e5903c67956707948b1de370b807e3aad395b7

### System information

macOS 13.1

### Issue description

Script classes are not regenerated project-wide after first import. See the reproduction steps below.

This is a huge problem for large games since a class may not have all of its dependencies ready by the time it comes to parsing the script, so it doesn't get registered on the first pass, and there are no other passes. The only solution is to manually open every single script and save it (potentially multiple times if there are long dependency chains).

The symptom is happening as of #70557, but the root cause was still present before that PR. If I revert that PR, open the reproduction project, and then instead of deleting the below file I empty out the `_global_script_class*` members, A and B do not regenerate (but they do if you open and save them). This has become a serious regression because the class list is no longer saved to version control, so you can end up in a situation where deleting `.godot/` results in a broken project until you manually open and save every script (for every developer, every time they delete `.godot/`).

### Steps to reproduce

1. Download an open the below minimal reproduction project.
2. Look at the generated `.godot/global_script_class_cache.cfg` file. Both A and B will be in there (good).
3. Close Godot and delete this file.
4. Open Godot again.
5. Look at the lack of a `.godot/global_script_class_cache.cfg` file. It is not regenerated (bad).
6. Open the `a.gd` script and save it.
7. Look at the generated `.godot/global_script_class_cache.cfg` file. Only A will be in there, but B will not (bad).

### Minimal reproduction project

[GlobalClassMissing.zip](https://github.com/godotengine/godot/files/10515105/GlobalClassMissing.zip)

}
		}
	}
}
/*
 * This method is responsible for loading a project.godot file and/or data file
 * using the following merit order:
 *  - If using NetworkClient, try to lookup project file or fail.
 *  - If --main-pack was passed by the user (`p_main_pack`), load it or fail.
 *  - Search for project PCKs automatically. For each step we try loading a potential
 *    PCK, and if it doesn't work, we proceed to the next step. If any step succeeds,
 *    we try loading the project settings, and abort if it fails. Steps:
 *    o Bundled PCK in the executable.
 *    o [macOS only] PCK with same basename as the binary in the .app resource dir.
 *    o PCK with same basename as the binary in the binary's directory. We handle both
 *      changing the extension to '.pck' (e.g. 'win_game.exe' -> 'win_game.pck') and
 *      appending '.pck' to the binary name (e.g. 'linux_game' -> 'linux_game.pck').
 *    o PCK with the same basename as the binary in the current working directory.
 *      Same as above for the two possible PCK file names.
 *  - On relevant platforms (Android/iOS), lookup project file in OS resource path.
 *    If found, load it or fail.
 *  - Lookup project file in passed `p_path` (--path passed by the user), i.e. we
 *    are running from source code.
 *    If not found and `p_upwards` is true (--upwards passed by the user), look for
 *    project files in parent folders up to the system root (used to run a game
 *    from command line while in a subfolder).
 *    If a project file is found, load it or fail.
 *    If nothing was found, error out.
 */
Error ProjectSettings::_setup(const String &p_path, const String &p_main_pack, bool p_upwards, bool p_ignore_override) {