[TASK] Better handling for common HERON data.

Issue Description

From notes on a meeting for this:

The basic problems that we discussed were how distribute the workshop materials and the associated ROMs that are used by them.

Some questions related to this are

Where to distribute this?
How to find the ROMs if someone moves or copies an input file? (Note that the relationship between the heron executable and data files is not constant for different install methods)

These need to work for three different cases:

Installation via a git clone
Installation via pip install
Installation via the standalone install (one stop)

For the git clone, the plan is that the ROMs will continue to be available in the clone. For the pip install and the standalone install these will need to be added. Since the current ROMs used by the workshop are significantly bigger than the HERON pip install, they will be a separate install. For the standalone install, the workshop materials and ROMs will be included.

In order to find the ROM data, we plan on first of all, moving the ROM data from various places in HERON/tests to HERON/data and adding a variable HERON_DATA (similar to the existing BASE_WORKING_DIR) that will point to HERON/data. If the environment variable HERON_DATA exists, it will use this for HERON_DATA. For git clones and the standalone install we will put logic in HERON so it can automatically find HERON/data. For pip installs, the user will have to manually set a HERON_DATA environment variable.

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

[ ] 1. Is it tagged with a type: defect or task?
[ ] 2. Is it tagged with a priority: critical, normal or minor?
[ ] 3. If it will impact requirements or requirements tests, is it tagged with requirements?
[ ] 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
[ ] 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

[x] 1. If the issue is a defect, is the defect fixed?
[x] 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
[x] 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
[x] 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
[x] 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?

idaholab / HERON