Allow users to provide user/case-specific user plugins as input

There are situations where users may want to provide case-specific material properties, component shapes, etc. that are typically provided by plugins. Thus, it’d be nice if users could point to a plugin that resides in an input file using a new setting (e.g. userPluginPath).

Since it’s related to the overall repeatability of the run, the new file should be hashed in the stdout and copied into the output h5 file for safe keeping.

This will also close #535

Sidenote: our pre-existing custom Python input related to the shuffleLogic and controlLogic settings could likely be merged into this capability at a later time to make this an overall cleanup.

I’ll take a stab at implementing this.

[ntouran]

Yeah so after more discussion it’s clear that this kind of thing would still be useful for some purposes, including doing rapid prototyping of test code that does things at special hooks. Effectively, this would allow people to use the plugin system as a convenient pathway for monkey patching during development/testing. I think as long as we put a strong indication near the ARMI version information that user plugins are in use, then we can maintain knowledge in the stdout about what code was actually run. Obviously, app-endorsed plugins explicitly imported and registered by the application should generally be used for actual qualified/traceable runs and analysis.

[john-science]

Yeah, I agree, thanks @sombrereau . If it ever happens laughing

I mean, it happened like a month ago.