I don't know what this test was trying to do, but it was wrong. Any
offset which is applied should be invisible to the clock's final
`CurrentTime` (and to the user).
This avoids it ever mutating the underlying track (aka attempting to start
it). Resolves the one caveat mentioned in
aeef92fa710648d4a00edc523e13c17ac6104125.
The editor clock, which is responsible for performing the seek, was not
aware of changes in control points due to reading from the wrong
beatmap. `loadableBeatmap` is not actually changed by any of the editor
components; `playableBeatmap` and `editorBeatmap` are.
For now this is changed to use `playableBeatmap`. A better follow-up
would be to use `editorBeatmap`, but it would probably be best to move
the beat snap bindable into `EditorBeatmap` first.
This matches osu-stable. When the track is running, seeking backwards
(against the flow) is harder than seeking forwards. Adding a mutliplier
makes it feel much better.
Note that this is additive not multiplicative because for larger seeks
the (where `amount` > 1) we don't want to jump an insanely huge amount -
just offset the seek slightly to account for playing audio.