Consolidating MapControls, OrbitControls ans TrackballControls

Continuing the discussion from #18483.

The problem with that approach is that, if we did that, why not also consolidate all loaders into a single file too?

For usability reasons I think it’s better to keep this API:

import { MapControls } from './jsm/controls/MapControls.js';
import { OrbitControls } from './jsm/controls/OrbitControls.js';
import { TrackballControls } from './jsm/controls/TrackballControls.js';

So the proble to solve is how to make these files consolidate code without changing the API.

[mrdoob]

The problem is that FirstPersonControls may not reuse the code that MapControls, OrbitControls and TrackballControls aims to reuse.

[Mugen87]

DataParser is essentially a utility class for example loaders, but we can’t serve it on the /examples folder or we’ll have problems “importing” on /js/loaders/.

That is good point. I think we can easier implement such refactoring as soon as exmaples/js is gone. How about waiting with this issue until we git rid of exmaples/js? In this way, we can head for a cleaner solution by utilizing the ES6 module magic.

One additional note: three.min.js is already too big and I really try to avoid code moving to core when possible.

In this case, it seems not appropriate to move CameraControls into the core. However, we might want to investigate if a generic Controls class could be developed which serves as a base class for all controls. A common interface/behavior for stuff like connect(), disconnect(), dispose() and event handling might be interesting.