[TASK] Add additional error handling for C++ module imports to be able to run RAVEN without building RAVEN

[j-bryan]

---

Issue Description

Is your feature request related to a problem? Please describe.
With recent changes to RAVEN to decrease dependence on certain C++ modules, it should be possible to run many RAVEN capabilities without building RAVEN. However, some module imports break when RAVEN is run without building. It would be nice to be able to use RAVEN capabilities that are pure Python without needing to build RAVEN first.

Describe the solution you'd like
Add additional handling of imports that fail when RAVEN hasn't been built. Crow imports appear to be the most common problem, but other modules (e.g. AMSC) may cause similar issues. Additional handling of crow imports in the relevant util functions should handle the failing crow imports throughout RAVEN.

Describe alternatives you've considered
Lazy imports could be used instead of top-level imports so that the import fails only when the module would be used in a class or function. This type of handling must be done at every instance of failing imports.

---

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.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 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)?
• 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)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?