feat!(?): Do not remove loader unless explicitly required

[MartinZikmund]

This change undoes the Persistent background changes made in #692, because it turns out they are not the crux of the problem.

When the WASM app loads, after the bootstrapper is done, it currently removes the loader (.uno-loader) and then the app itself is initialized. This takes a few hundreds of milliseconds after which Uno itself creates its own "loader" (#uno-loading). Unfortunately, those milliseconds are a problem - as they mean that a plain white background will flash there which is very jarring.

This PR changes the default behavior of the bootstrapper to keep the .uno-loader in place even after initialization is done until some child is actually added to uno-body. This means that it will stay displayed while the actual app is loading, and when it indeed adds its #uno-loading element it should remove bootstrapper's .uno-loader afterwards.

Question for @jeromelaban - is this actually a breaking change? Are there any non-Uno apps which would not add content to .uno-body - resulting in the loader not disappearing?

[jeromelaban]

@MartinZikmund I don't think there are, though we must ensure that the loader actually removes itself when not using uno.ui.

[MartinZikmund]

@jeromelaban Is there any way to check if the app is Uno.UI-based? Alternatively it could be a flag in the manifest like "shouldRemoveLoader" that would be false by default and people could explicitly set it to true when needed.

[jeromelaban]

@MartinZikmund I've added the PR validation to see the result..

The new behavior has to be opt-in only, and it may be disabled when some flag has been set (optionally by Uno.UI).

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://white-river-0087b630f-699.eastus2.1.azurestaticapps.net

[MartinZikmund]

It seems to work in the sample. The change applies only in case the HTML contains the loader inside of .uno-body, so that could be a good enough safety measure. But we can discuss further next week

[MartinZikmund]

@jeromelaban is this mergeable?

[jeromelaban]

I think it is!