[3.4] Profiling - fix frame_time measurement

[lawnjelly]

When the sync_after_draw feature was on it was possible for the profiler's frame_time measurement to be incorrect. This fixes this problem by storing the raw measured time for use by the profiler.

Notes

• This is just a small bug fix for the profiler when sync_after_draw is on, doesn't affect behaviour.

Discussion

I've been taking a quick look at the general area of the timing profiling as a result of the discussion in #48555. The current profiling could be improved but it needs a bit of time spending on it, more than I wanted to do in this PR.

A few things to note:

• The variable names in the whole profiling code path are desperately in need of improvement (time is used both to denote an absolute time, and a delta, for instance).
• 32 bit float is used which may be problematic when converted to deltas.
• The physics tick delta is passed every frame to the remote debugger and stored, despite the fact it is a constant.
• Users could be confused that the profiler measures wall clock time, and not the delta that is passed to _process after smoothing and jitter fixes etc have been applied. We could consider profiling the smoothed delta instead of the fixed physics tick delta. It would be much more useful to users.

[akien-mga]

Thanks!