Provide control over which replayed core is which output drmemtrace stream

[derekbruening]

In the drmemtrace scheduler, some sort of full control over which replayed core should be which output stream would be good, as the comment in read_traced_schedule() says:

// We initially number the outputs according to their order in the file.
// XXX i#5843: Should we support some direction from the user on this?  Simulation
// may want to preserve the NUMA relationships and may need to set up its simulated
// cores at init time, so it would prefer to partition by output stream identifier.
// Maybe we could at least add the proposed memtrace_stream_t query for cpuid and
// let it be called even before reading any records at all?

As a first step, we should at least sort the cpuids, as raw2trace inserts them in whatever hashtable order they were in, which is essentially random. E.g., on 2 sockets, the order for one trace has the 2 sockets completely intermixed: 4185,70,4207,4126,4129,69,... (the top bit 4096 marks the 2nd socket). This means the replay will not match the original order.