Determine the control flow necessary to implement tally multipliers

[gonuke]

Previous steps have ignored, for the moment, how to access tally multipliers, especially nuclear data based multipliers, and apply them to tallies.

This will require some discussion, probably in a meeting, once we have the other data structures finalized.

[kldunn]

General tally multiplier support has been added to the TallyManager. Multiplier values are added to a vector stored in the TallyEvent that is independent of the list of tally observers (in the future it may be better to use an unordered map from the C++11 standard). These values are accessed by a multiplier ID (i.e. vector index) that is stored in each TallyInput. This allows different tallies to use the same multiplier ID without having to store/update it twice per event. The tallies can then access this multiplier value in their compute_score methods using TallyEvent::get_score_multiplier, which returns the current particle_weight * multiplier value (or just particle_weight if multiplier_id is not valid).

In DAG-MCNP, the multiplier ID is related to the fmesh index. If no multipliers are used, then none are added to TallyManager. However, the TallyManager::updateMultiplier method is currently still called for these tallies from MCNP even though it doesn't do anything. This is how the original tally multiplier implementation worked for DAGMC tallies as it called dagmc_mesh_score every time, whether or not multipliers were used. As a future performance improvement, if needed, the fmesh tallies that actually have multipliers can be stored in an array so that we only update the ones that need to be updated. Alternatively, we could use a new DAGMC tally card instead of the existing FMESH tally card.

These changes will be merged back into meshtally_refactor by Monday.

[kldunn]

Multiplier changes have been put back into meshtally_refactor so putting this issue into review status.