Implement standardized error message output including the stacktrace

[tkol2022]

💡 Summary

Recently we analyzed how to modify ScubaGear to ensure that error message print statements are standardized and that they include the stacktrace. We also had problems that in some instances the stacktrace was wrong so that needs to be addressed too. Issue #1005 presents a solution with some sample code. The purpose of this issue is to formally incorporate those enhancements into ScubaGear.

Implementation notes

• Codify the enhancements discusses and prototyped in Decide how to modify ScubaGear so that it shows the source line where errors occur #1005
• The code must satisfy and be tested against the conditions noted below.

Conditions the code must satisfy:

• Make sure error messages print the stack trace so that we can troubleshoot when problems occur.
• Make sure the stack trace indicates the correct line where the error occurred. See example in comment below where the catch block inside the Invoke-ProviderList prints the wrong source lines.
• Make sure the error handling logic correctly aborts execution under export provider failures. For example, right now the orchestrator continues to run additional logic if Export-AADProvider fails, which might not make sense.

[tkol2022]

At the stand-up meeting on 9/30 we received some feedback from the dev team that creating a new module to house the error message handling is the preferred option instead of putting the new function into an existing module.