Closes: #1170 Closes: #577 This PR implements a new Clock api to manage the core main loop. Clocks hide the implementation detail of how the mainloop runs, users just knows that it ticks somehow. Clocks additionally encapsulate any related browser timing, like `performance.now()` 1. `StandardClock` encapsulates the existing `requestAnimationFrame` api logic 2. `TestClock` allows a user to manually step the mainloop, this can be useful for frame by frame debugging #1170 3. The base abstract clock implements the specifics of elapsed time * The new `maxFps` option is added to the engine constructor options. This is achieved by exiting the mainloop early in clock if the current elapsed time does not match the desired fps. This can be useful when you want to deliver a consistent experience across devices. ## Some fixed bugs that were illuminated as part of this - Excalibur's initialize flow was flawed, this PR refactors the start() to mean "ready for game code to run", before it actually meant resources loaded and player clicked play - Play button wasn't positioned until first update, now positioned on init - Systems were not initialized until first update, now initialized with the scene ## Current game start flow ### After this PR (consolidate init before start resolves) 1. game.start(loader) 2. clock started 3. load resources 4. compute resolution 5. run engine/scene/ecs system initialize 6. emit ready 7. start the game ### Before 1. game.start(loader); 2. mainloop raf started 3. load resources 4. run some initialize logic 5. compute resolution 4. start game 5. run initialize logic ## Changes: - New Clock API for managing the mainloop - Added `maxFps` engine option to constrain to a maximum fps - Updated fps sampling to be more useful - Updates the tests to use the new TestClock (fun side-effect tests are ~20 seconds faster in CI!) - Some small bug fixes that are related to clock timings