Resolve order of initialization error reading startup file,
support postponing running wm_file_read_post until Blender
has been initialized.

Deferring updates allows duplicate initialization to be removed from WM_init.

Even though moving Python initialization before reading the file would probably fix T89046,
there are other potential problems that could be caused by attempting to initialize the blend file
before blenders subsystems have been properly initialized.

For example: Evaluating the depsgraph and drivers before open-subdiv have been initialized.

Alternative solutions:

Split Preference/Startup Loading P2317

In principle this is a cleaner design, however it doesn't work well because preferences loads the keymap and the keymap is stored in the window-manager which wont be created if the file data has not been loaded.

This could be made to work if the keymap was moved out of the window-manager, but that's a much bigger refactor.

Read Preference/Startup "Last" P2318

This is quite close to working, but has some drawbacks.

• Making sure none of the initialization functions don't use U anywhere is error prone.
• We may still end up with order of initialization problems where a sub system requires user preferences in order to initialize properly.
• Delaying loading file data means there is no window-manager when Python initializes. This causes an exceptions as Python tools need to register their keymap. We could defer registering keymaps, or create a dummy window manager so a keymap can be setup, from looking into this neither are all that straightforward.