BMC Dump: Refactoring plugin parser infrastructre

[ojayanth]

BMC Dump Plugin infrastructure in currently placed in phosphor-debug-collector repo.
Proposal is to move plugin into repo specific based on the use case. This design approach will distribute the the plugin ownership to repository maintainers.
Proposed changes: Move install_dreport_user_script(script_path, d): equivalent functionality from phosphor-debug-collector recipe to new class and application can utilize this by inheriting this. this would help the application can control dreport user plugins.
FYI @bradbishop @artemsen

[artemsen]

The new bbclass looks like an "intermediate solution". I think it would be better to register a dreport's plugins at runtime via D-Bus. This is a more flexible solution and it would obviate the need to use bash commentaries as plugins setup.
For example, we may add some commands to phosphor-debug-collector interface:

AddPlugin(path, runLevel, priority)
RemovePlugin(path)
GetPlugins(runLevel)

and call 'GetPlugins' from dreport script (with busctl) to execute externally registered handlers.
To simplify the dreport interface I would call external plugins with parameters instead of using environment variables, something like this:
extplug dumpPath runLevel

[devenrao]

probably we can try meson build system to copy the files and create soft links based on the build type setting open-power/ibm/xxx