Add support for plugins in fnext

[riconnon]

• What I did

Preliminary support for dynamically loadable extensions. Doesn't (yet) include ability to specify loading them at runtime.

• How I did it

Uses golang "plugins" to load plugins from shared libraries

• How to verify it

Good question... I've verified it myself using my extensions but maybe we should have some automated tests with dummy plugins.

• One line description for the changelog

Add support for dynamically loading extensions

• One moving picture involving robots (not mandatory but encouraged)

[rdallman]

i'm 'with the program' on moving call overrider to fnext, short of getting rid of it altogether. i do think that we should probably avoid adding the .so plugin stuff however and just have the package using the call overrider bake it in at compile time like all the other plugins in fnext - i appreciate trying it out, it's something we've been curious about for a while, but there is not strong buy in from what i can tell at this time anyway (we could have a wider discussion, of course...) and we'd need deployment tools to manage that among other things.

[riconnon]

I would also prefer to see CallOverrider removed altogether. My initial thinking was that if the "exts" map that it handles was moved to the call object then this would just be a CallListener Happy to go through and do that work instead if it's preferred.

[rdallman]

My initial thinking was that if the "exts" map that it handles was moved to the call object then this would just be a CallListener

it's early, but that sounds like a great idea to me