Torus and simplewan each have problems precluding them from the current
scheduling fix:
- simplewan - each "device" has N input/output ports. It can't simply tell the
  scheduler when they are (it is?) idle because the scheduler doesn't know which
  packets go to which ports
- torus - also has N input/output ports (two for each dimension). Also, the same
  routing "queue" (via the "next_link_available_time" var) is used for incoming
  and outgoing messages, so we can't guarantee the scheduler that we'll be
  available at time x (an incoming msg could arrive and then be routed at time
  x-1). This isn't a problem for the dragonfly network as terminals aren't
  intermediate routers. Ideally what needs to happen here is for the
  intermediate packets/chunks to be queued up in the scheduler.

- previously, packet issues were done without any consideration for device
  availability - within epsilon, preventing any meaningful scheduling
- enabled for loggp only, other networks will be incorporated shortly

Integrating DUMPI's MPI trace replay with model-net. Currently, supports replaying MPI point-to-point messaging on top of torus/dragonfly and simple-net network models.

- N priorities processed in increasing order
- queue for priority i not touched until 0...i-1 queues are empty
- example injection API usage shown in test program
  - currently, only the priority scheduler has need of it

All configuration now proceeds on a per-LP level, and requires separate
registration and configuration calls, as seen in the test programs.
model_net_set_params is no longer used, and is replaced by model_net_register
and model_net_configure. The dragonfly network, having two LP types bundled in
the same code-path, is special-cased in the registration code.

LP-mapping in model-net now has the following defaults:
- counts via codes_mapping_get_lp_count are now with respect to the calling
  network LP's annotation.
- when looking up network LPs via
  codes_mapping_get_lp_info/codes_mapping_get_lp_id, the annotation of the
  calling network LP is used. Hence, routing now occurs only between LPs of the
  same annotation. If the destination LP's group specified by model_net_*event
  does not contain a modelnet LP with the same annotation as the modelnet LP in
  the sender's group, then an error will occur (in codes_mapping).

Known Issues:
- modelnet users currently cannot specify which modelnet LP to use in the case
  of multiple modelnet LPs in the sender's group. This will be fixed in future
  commits after a consensus is reached on the best way to expose this
  information.

- "modelnet" parameter in cfg is now a no-op
- "modelnet_order" parameter in cfg is required,
  listing order in which networks are indexed to
  the model
- modified "model_net_set_params" signature
- updated tests to use the new interface

Adding collective modeling functions in model-net (currently only dragonfly/torus models support it)

- NOTE: shim just forces packet size to a huge number