Adding group level mapping in the dragonfly: multiple routers can now be specified in the config file

Adding rough version of history window in dragonfly adaptive routing. Updating the simulation to display more stats

Adding further updates to the dragonfly routing (statistics for adaptive routing updated, conditions for queue congestion sensing updated)

1) Adding dragonfly adaptive and prog-adaptive routing algorithms--- still testing with more workloads and crosschecking the computation 2) Two bug fixes in credit-based flow control

Introduced back when I added a "last-hop" queue to allow prioritized
messages to go to the front of the set of msgs loggp is to receive. Haven't yet
put it in other models (simple*), so RNG bug doesn't affect there yet.

same var name used for the "sequencing" macros

Tired of explaining that it's not a good representation of a WAN. Instead, it's
now a simple point-to-point latency/bandwidth model.

NOTES:
- torus does not use it, as it has some routing logic preventing direct usage.
  It probably can be done, but I'll leave that for later.
- collectives in torus, dragonfly don't use it yet.

(have NO idea how the triton tests passed without this...)

Rather than model-net LPs directly sending messages to other model-net LPs, LPs
can route the intended message through the scheduler interface to be queued up
for reception by the receiver (see the diff of loggp.c). This has the benefit of
    enabling things like priority and fairness for N->1 communication patterns.
    Currently, no packetizing is supported, and I haven't yet wrote checks for
    it - beware.

Loggp is currently the only supported model. simplenet could also be supported
without much trouble, but I doubt there's any demand for it at the moment.  This
should NOT be used by the dragonfly/torus models, as they have their own routing
backend.