Revise timing metrics collection to avoid unaccounted-for time

[robertknight]

In the GPT-2 medium model, about 6% of the runtime for each step was reported as "[Other]", which is the difference between the total time for the run and the sum of individual operator timings. Upon analysis, this difference turned out to be a combination of:

1. The overhead of getting the time with Instant::now
2. Rounding and accumulation errors due to storing timings in various resolutions and using single-precision float operations to sum timings
3. Setup time spent in Graph::run_plan before the start of the main loop

The Instant::now overhead on macOS (Intel) is about 30% rdtsc + fences and 70% call overhead according to samply.

This commit addresses these as follows:

• The number of Instant::now calls has been reduced from 2 to 1 per step, with each call capturing the total time for the whole step, now just the call to Operator::run. This means that output processing for a step is now accounted for in the time for that step.
• Operator timings are now represented, and summed as, Duration values. These are integer counts of nanoseconds, avoiding issues with rounding and float accumulation.
• The run timing is now reported as the sum of operator timings, excluding setup before the main loop.

The Timer utility type was removed as it is no longer used following these.