[v10] Prevent elapsedTime from being reset unescessarily

[AlaricBaraou]

I don't think that setFrameLoop should affect elapsedTime.

In my use case, I temporarily set frameloop to always before reverting back to demand, with the current version it mess the elapsedTime.

This PR only reset elapsedTime when using never, which seem to be the initial intended use case.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 3700905:

Sandbox	Source
example	Configuration

[DennisSmolek]

The new API with the scheduler is a bit different but does the same (will get over today actually) and doesnt use THREE.Clock or THREE.Timer
(Note, three itself has moved from Clock to TImer and even that they seem to be dropping in favor of TSL time())

So the current operations though match the old, when you change the frameloop mode it stops the running loop. When you hit start() it resets the elapsed time (and frame count).

The problem is how do you want pause/stop/resume to effect delta and elapsedTimes?

What I've come up with is to reset the delta on start/stop and adjust the elapsed time and createdAt point.

So if the frame is going and you hit scheduler.stop() (which happens on frameloop changes)
We mark the stoppage time and elapsedTime sits.
If you then waited 5 seconds and hit scheduler.start()
The old system would reset everything to 0 as if a new loop was created.
Elapsed goes to 0 and anything that uses it for position would jump back to its start.

However If we persist the elapsedTime though from the original clock though we would be 5 seconds in the future which is also incorrect (likely why they reset it to 0)

So what I did is trim the stoppageTime from the loop createdAt meaning elapsedTime is relative to the total time the loop was running, excluding when it was stopped.

This also solves when you go from a different tab/window and back and the scene jumps wildly..

I'll update when the branch is over

[AlaricBaraou]

I see, sounds like one of these issues where it's impossible to satisfy every use case.
Thanks! Then I'll wait until I see the new version.