startup trace: Fix abort and restart

Before this change, AbortAndRestart was not working for startup tracing.

The reason being: In the newly started session, we were not able to
recognize the abortion of previous startup trace properly. As a result
trace macros/lambdas remains associated with old trace writers, because
TLS state was not updated properly. Since old trace writer was bound to
`kInvalidTraceBuffer` when we called AbortStartupTracing, newly written
traces were also getting dumped into trash instead of new buffer.

It remained bound to `kInvalidTraceBuffer` even after main tracing
session was started, because main tracing session also adopts existing
data sources (which were instantiated for the startup trace).

Note that: After restarting startup tracing, if we had trace macros in
some different thread (different from where we used trace macros before
aborting), then it was working fine.

In the abortion of start up trace, we were already doing
`TracingMuxer::generation_++` to trigger the validation of thread local
trace-writter in the fast path. However that validation was incorrect
because it was not taking `DataSource.target_buffer_reservation_id`
into account. It was only taking `DataSource.target_buffer_id` into
account. Since the `target_buffer_id` remains zero if the data source
was started for the startup tracing, misreporting of
trace-writer-validity was causing fast-path to not create a new
trace-writter from global muxer.

Fix : Take `target_buffer_reservation_id` into account for checking
if the static-state of a DataSource changed significantly to require a
new trace-writter by fast path.

Change-Id: Ic1ead33896ae5ab89db473429105dcdd633b79a9