Make ReSolve xSDK compliant

[pelesh]

This may take a lot of work, but xSDK policies contain some sound software sustainability practices and are good to have implemented anyways. Here is the checklist from xSDK policies v1.0.0:

• M1. Support portable installation through Spack.
• M2. Provide a comprehensive test suite for correctness of installation verification.
• M3. Employ user-provided MPI communicator (no MPI_COMM_WORLD). Don't assume a full MPI 3
  implementation without checking. Provide an option to prevent any changes to MPI error-handling if it is
  changed by default.
• M4. Give best effort at portability to key architectures (standard Linux distributions, GNU, Clang,
  vendor compilers, and target machines at ALCF, NERSC, OLCF).
• M5. Provide a documented, reliable way to contact the development team.
• M6. Respect system resources and settings made by other previously called packages (e.g. signal handling).
• M7. Come with an open source (BSD style) license.
• M8. Provide a runtime API to return the current version number of the software.
• M9. Use a limited and well-defined symbol, macro, library, and include file name space.
• M10. Provide a publicly available repository.
• M11. Have no hardwired print or IO statements that cannot be turned off.
• M12. For external dependencies, allow installing, building, and linking with an outside copy of external software.
• M13. Install headers and libraries under <prefix>/include and <prefix>/lib.
• M14. Be buildable using 64 bit pointers. 32 bit is optional.
• M15. All xSDK compatibility changes should be sustainable.
• M16. Have a debug build option.
• M17. Provide sufficient documentation to support use and further development.

This is going to be significant team effort. @rcrutherford will coordinate activities and create issues (blocking this one) for specific policies compliances.

[pelesh]

Portable installation through Spack delivered in #10

[cameronrutherford]

@pelesh we really need a 0.1.0 or equivalent release if we want to try and build for xSDK 1.0.0. Is that possible?

[pelesh]

The documentation still needs some polishing up, but I think we are there in terms of xSDK compliance. @cameronrutherford and @ryandanehy, please chime in.

[cameronrutherford]

I think we are ready for review

[pelesh]

Closing per @cameronrutherford review.

[cameronrutherford]

We still need xSDK review and to be included as a part of the list of packages?