Better integration for external plugins (Plugin API)

Nobody has claimed this yet.

## Feature Request

Opening a feature request kicks off a discussion.

### Current behavior:

If I were a distro maintainer or a sysadmin wanting to distribute plugins for users, the current solution (execd) makes that practically impossible.

* There's no discoverability, meaning you can't list available external plugins.
* Configs & paths are separate from standard telegraf configs & paths.
* This requires users have to go create some new directory and/or file for every plugin instance.
* Users also have to configure the plugin in 2 different locations (one for the plugin config, one for the telegraf config to run the plugin).
* Leads to confusion where some directives go. Do things like `tagpass` or `interval` go in the telegraf config, or the plugin config? (I know the answer, but the user may not)
* Command line arguments are non-standard, meaning the user has to take the plugin and run `--help`, `-help`, `-h` or some other unknown help mechanism.
* Telegraf will dump sample configuration but won't include plugins. This will require the user to either call the plugin with `--sample` or some other flag (if it even supports it), or go hunt down the web site.
* Restart delay is too slow. It shouldn't take several seconds to restart a failed plugin, but also shouldn't pound the logs & CPU if it goes into a restart loop.
* Data transfer is lossy. If an output/processor plugin exits, any data in the buffer is lost.
* Have to run multiple plugin processes to serve multiple configurations. This wastes system resources, especially if the plugins are in go, or otherwise statically linked.

### Proposal:
* Implement a bi-directional API between telegraf and external plugins.
* Add a telegraf config directive for a plugin directory. Any executables in this/these directories will be assumed to be telegraf plugins adhering to the external plugin API.
* Allow a single plugin process to service multiple instances (the API should support multiplexing).
* Maybe allow a single plugin process to service multiple types. I'm somewhat undecided here, but it might be useful to allow a single binary to provide both an input & output, or multiple different outputs, etc.
* Add API calls for things like discovering the plugin types (input/output/processor), getting the config sample, passing the config (starting a new instance), etc.
* Add an acknowledgement mechanism and don't drop metrics from telegraf until acknowledged by output/processor plugins.
* Only add a restart delay if last start was less than $delay seconds ago.

In essence, once a plugin binary is installed, from the user's perspective, it should be indistinguishable from a built-in plugin.

I don't really care much what the actual API itself looks like as long as it's performant. Though protobuf over stdin/stdout would be my first thought (gRPC?). Whatever it is, for plugins written in go, the underlying API should be hidden behind a provided SDK (kinda like the plugins/common/shim that currently exists).

### Use case:
* Make external plugins much easier for users to consume. Users will no longer have to go hunting to find a plugin's path, it's command line arguments, or its config settings.

* Make it easier for developers to write and distribute plugins.
* Distro maintainers and system admins can put plugins in a standardized path and they will behave just like built-in plugins.
* Software vendors could include telegraf plugins with the software.

* Make it possible to externalize many of the built-in plugins *(note this issue is not saying this should be done, just that it becomes possible. See: [#9615](https://github.com/influxdata/telegraf/issues/9615) / [#9556](https://github.com/influxdata/telegraf/issues/9556))*, and implement current plugin proposals as external.
* Allowing faster/asynchronous development cycles, better code, etc.
* Make binaries smaller.
* Allow plugins to use different versions of dependencies.
* Allow running plugins with different permissions.

* Allow plugins with different licenses to be distributed independently.

No implementation files or tests are named. Start by reviewing the current execd solution and the plugins/common/shim mentioned in the proposal, then map how external plugin discovery, configuration, process control, multiplexing, and acknowledgements would fit Telegraf. Done would require an agreed, performant bidirectional Plugin API that makes external plugins behave like built-ins.

Written by the indexing model from the issue text.