[Enhancement] Making the package more malleable in non-breaking ways

[Orrison]

Howdy!

I am very interested in using this package but there are a few tweaks to the way it works that would make it perfect for my use-case. I believe a couple of changes to the way this is set up could allow folks like me to make those tweaks, but not break anything how it currently is.

If you want to let me know which of any of these you would be interested in, if any. I can open some PRs if you would like.

Non-Breaking

• Dispatch Events in key areas
  • Firing Events in some key areas is an easy way to allow folks to hook in with a listener to respond to certain points in the operations process
  • Some examples I can think of are:
    • When OneTimeOperationsProcessCommand starts
    • When OneTimeOperationsProcessCommand finishes
    • When OneTimeOperationProcessJob starts
    • If OneTimeOperationProcessJob succeeds
    • If OneTimeOperationProcessJob failed
  • This is perfect to help with CI/CD to do things like send Slack or email notifications if an operation fails, etc.

Mostly Non-Breaking

• Allow package users to provide their own classes
  • By making use of the Service Container and/or the config file for the package we could allow package users to override certain classes like the OneTimeOperationProcessJob for example
  • I believe we should be able to use the Service Container to resolve to the current classes, and give package users the ability to to re-bind in their app Service Providers. Which would make this a complete non-breaking change. But if not possible once dug into, another good route is defining which classes to use in the config, setting the current ones as the package defaults. This would be slightly "breaking" as it would require people to update their config file if they had published it already.