workflow involves more than just `sst-core` and `sst-elements`

[lpsmodsim]

An important aspect I learned at the SST user community meeting this week was the relevance of the holistic workflow. I previously learned about the DES lifecycle in sst-core. Now I'm considering a broader view:

1. learning about DES. Some users are not familiar with DES
2. learning how sst-core provides a framework for DES
3. comparing SST to other options to determine whether SST fits the user's desired outcome
4. reviewing components and subcomponents available from sst-elements and either leveraging those or modifying them or creating novel elements to simulate a model of interest.
5. specifying the graph of components/subcomponents/links using either (Python driver file) or (ahp_graph) or (single JSON file) or (set of JSON files, one per rank).
6. (optional) visualizing of the component graph prior to simulation
7. running the simulation using SST
8. live logs (for review and for visualization) and debugging during execution
9. reviewing logs and stats after the simulation. CSV, HDF5, Elastic
10. generating plots (in Excel, in Python, etc)
11. documenting the simulation configuration and results for future reproducibility

Documenting the workflow above would be useful to explain on https://sst-simulator.org/sst-docs/