Plot_mesh_tally revisions for usability & accuracy

I have been using plot_mesh_tally for a case I'm running and fixed a few things/made enhancements as I went along.  The following PR is the result of this work.  This PR includes the following:

  1. The user can now provide a command-line argument which is the statepoint file to load; this bypasses the file dialog completely
  2. If the statepoint file does not contain any mesh tallies, then the following actions are taken:
    * If using the command-line argument for the file to use, an error is printed on the command-line and the code just quits
    * If using the file dialog to select a file, a dialog box appears, stating the error, then asks if you want to abort or retry the file selection
  3. To avoid errors, the list of tallies presented to the user are only those which use mesh filters.  That is, if you have a tallies.xml file which defines 4 tallies, and only the last one uses a mesh filter, then the only option for which tally to select is "4"
  4. The use of statepoint.get_value was slightly off in that the get_value() routine uses fortran (1-based) indexing, where as plot_mesh_tally uses 0-based indexing.  This resulted in the displayed mesh image being off by 1 row and 1 column
  5. Finally, the displayed matrix was transposes and the origin set to the lower-left so that orientation of the image presented by plot_mesh_tally matches that created with the --plot command.

Changes to statepoint.py:
  1. Statepoint.py now uses np.sqrt vice math.sqrt.  This avoids errors when the sqrt((s2/n-s*s)/(n-1)) term is evaluated in generate_stdev().  I haven't investigated this fully, but it seems to occur when evaluating at the nu-scatter tally that is included by CMFD, and I have assumed it is just a result of poor statistics