* Decode Tree API updates.
-> Re-factor the decode tree API to:
   1)  remove the per decoder type creation functions  - CreateETMv4Decoder(...),
   replacing with a single CreateDecoder("Type"). 
   2) Use new structure to enable custom decoders - may be proprietary / binaries to 
   be used in the decoder structure.
   3) Make it easier to add a new decoder to the library source, without the overhead of 
   doing all the creation fns.

* STM "full decode".
-> This is simply to come up with a generic packet format that will consist of
   Master+Channel+<payload>,  where <payload> is [data]+[TS]+[marker/flag]. This
   combines a number of packets from the raw STPv2 format.

* ETMv4/PTM - decoder updates to handle advanced configuration.
-> Certain (currently unused by perf /  current hardware) configuration settings
   can alter the format of the trace output. One example is Return Stack -
   settable in the control registers for PTM/ETMv4, and removes some inline
   addresses. Decoder must use a follower to correctly trace when this is set.

* ITM packet processing and decode.
-> ITM is primarily an M class SW trace module. I wouldn't expect to see it on
   systems with STM, unless a companion M class was present.

*Data trace - ETMv4 / ETMv3
-> Differing solutions to data trace in v4/v3 - v4 is separate trace stream
   completely, output at trace ID <instruction_trace_ID>+1. ETMv3 is inline with
   the instruction trace.

Cortex-A cores do not support this architecturally. On R and M profile cores it
is an option. There are scenrios in future that could see linux on R cores, plus
on something like Juno it is possible to switch on trace for the SCP
(M class processor). So at some point data trace