extend firefly-core with plugins without requiring a fork

It seems that the only way to package a plugin into firefly-core is to make code changes in the `firefly` repo itself. Which means that the plugin developer effectively needs to maintain a fork and track origin.

A couple of thoughts on how we could make this more elegant
- rather than ( or at least, as well as) having a hard coded list of [transport providers](https://github.com/hyperledger/firefly/blob/main/internal/events/eifactory/factory.go#L30-L34) we could introduce a way to dynamically register implementations of the `event.Plugin` interface. i.e. similar to the registration of policy engines in [firefly-transaction-manager](https://github.com/hyperledger/firefly-transaction-manager/blob/main/pkg/policyengines/registry.go#L45)
- move the [bootstrapping code](https://github.com/hyperledger/firefly/blob/main/cmd/firefly.go#L101) into `pkg` so that a plugin developer can build their own golang executable to extend `firefly-core` with their plugin and only provide a very thin `cmd` package that simply invokes the `firefly-core` bootstrap ( after registering the plugins as my first bullet 1)

Full disclosure: I am not a golang expert so there may be a much more elegant way to achieve this that I am not seeing.