Scanners should include "storage wait time" per scan node

We have TotalStorageWaitTime per fragment instance, which aggregates various things like times spent waiting for the I/O manager and time spent in the Kudu client. This is useful but often we want to understand why a specific scan is slow. This is tricky because TotalStorageWaitTime and the various scanner thread timers in the profile are in different subsections and don't measure comparable things if there are multiple scans in the profile.

We should also include this timings in the scan profile to address this.