AppBase refactored out of the Application to allow for tree-shaking

[mvaligursky]

Based on #3949

This is an initial refactoring of AppBase class out of the Application. There will be follow up PRs removing some additional functionality / imports from AppBase.

The situation before this PR: we have an Application module, which imports and instantiates every other module the application needs - even when the user's application does not need them, limiting the usefulness of tree shaking.

This PR extracts a BaseApp class from the Application, which holds and uses all other instances of classes as before, but does not instantiate them. This part is left in the Application.

This allows the user to instead of using Application with all dependencies, to simply use the AppBase, and decide what dependencies are needed.

As an example, at the moment this is what users do to create application, which imports all modules from the engine:

const Application = new pc.Application();

this PR allows to allocate AppBase, and import only what is needed:

import { AppBase } from './app-base.js';
import { AppCreateOptions } from './app-create-options.js';
import { WebglGraphicsDevice } from '../graphics/webgl/webgl-graphics-device.js';
import { RigidBodyComponentSystem } from './components/rigid-body/system.js';
import { CollisionComponentSystem } from './components/collision/system.js';
import { Lightmapper } from '../scene/lightmapper/lightmapper.js';

const createOptions = new AppCreateOptions();

// user can import and create webgl or webgpu based on the needs
createOptions.graphicsDevice = new WebglGraphicsDevice(canvas, graphicsDeviceOptions);

// import and use only components that are neded
createOptions.componentSystems = [
            RigidBodyComponentSystem,
            CollisionComponentSystem
];
  
// import and use lightmapper only when needed
createOptions.lightmapper = Lightmapper;
      
const app = new pc.AppBase(canvas);
app.init(createOptions);

The way this works is that user imports the module, and assigns a class constructor to the createParameters. This allows AppBase Internally to call new on that object to allocate the instance. This removes the need for the user to call the constructor at all. There are few advantages here:

• we can internally change the constructor parameters as needed
• the user does not need to understand parameters to constructors, which can be hidden from docs (as currently)
• we can call constructors in order we need internally

example for this. We use this:

createOptions.lightmapper = Lightmapper;

instead of

createOptions.lightmapper = new Lightmapper(device, app.root, app.scene, app.renderer, app.assets);

Basic testing to confirm we load less modules (using minimum app)

[LeXXik]

It would be great, if we would have access to components selection from the Editor. The builder would then assemble an application based on that configuration.

[mvaligursky]

It would be great, if we would have access to components selection from the Editor. The builder would then assemble an application based on that configuration.

Yes, in the longer term the plan is to certainly allow tree shaking in the Editor, likely in a form of some builder. The complexity we need to solve after this PR is the scripts - as those are not modules (for now anyways), and so we cannot easily find out what needs to be imported to the application.