[drmemtrace] Differences in trace header presentation to analysis tools

drmemtrace analysis tools can be run in either the online mode (which is performed during the app run), or offline mode (which is performed on a drmemtrace trace stored on disk). There may or may not be trace "skipping" involved using the -skip_instrs and -skip_to_timestamp options.

There seem to be subtle differences in how the trace header is presented to the analysis tool in different modes of analysis described above. The differences are in what memref_t records are presented to the process_memref/parallel_shard_memref API of the analysis tool, and the values returned by some memtrace_stream_t APIs.

* memtrace_stream_t does not provide the trace filetype upfront (and similar trace header related information like the trace version) in online trace analysis

https://github.com/DynamoRIO/dynamorio/blob/f016b8fdf8206c44f795bd549127c234ef63eb3e/clients/drcachesim/scheduler/scheduler.h#L1067

* The trace header `memref_t`s like the version and filetype are not presented to process_memref/parallel_shard_memref when trace skipping is involved

https://github.com/DynamoRIO/dynamorio/blob/f016b8fdf8206c44f795bd549127c234ef63eb3e/clients/drcachesim/scheduler/scheduler.h#L271

The above nuances make it complex and error prone for a tool to perform initialization that requires trace header related data; e.g., for the decode_cache_t which requires the trace filetype for decode_cache_t::init. decode_cache_t::init suggests working around these nuances by using dynamorio::drmemtrace::memtrace_stream_t::get_filetype() just before processing the first instruction memref in the process_memref() or parallel_shard_memref() APIs.

https://github.com/DynamoRIO/dynamorio/blob/f016b8fdf8206c44f795bd549127c234ef63eb3e/clients/drcachesim/tools/common/decode_cache.h#L455

It will be nicer to simplify this and make it less error prone:.

* If we expect the user to use the memtrace_stream_t APIs for everything, maybe we shouldn't provide the header entries at all to process_memref, so there's no confusion about where the header data should be obtained from.

* Since it can be hard to migrate all tools (especially the ones not in this repository), alternatively we could choose to repeat the global trace headers if skipping from the start, since the user likely always wants to know the header details.

* And maybe we should also delay calling initialize_stream and parallel_shard_init_stream until we know the stream object is fully usable.