• Updated associated README.md.
• Wrote appropriate unit tests.

resolves: #8352

This PR adds the machinery to persist the "state" of a plugin over multiple telegraf runs. A plugin's state is defined by the plugin itself and only has the requirement of being serializable (to JSON currently). The framework consists of

1. An interface definition that plugins have to adhere to provide a state (GetState()) and receive a state on load (SetState()).
2. A storage backend to persist the data. Currently a JSON file is used.
3. Means to derive a unique ID of plugins that is consistent over multiple runs of telegraf. Here, currently the plugins name and TOML configuration is used. That is, the ID is consistent over multiple starts of telegraf iff the (effective) config is unchanged.
4. The logic of getting and setting states in the agent.

Additionally, we provide ways to push updates to the persister (UpdateState()). However, there is no guarantee of when the state is actually written to disk. Last but not least, there is a way for the plugin to provide an ID itself by implementing GetPluginStateID().

To decide which persisted state belongs to which plugin, we compute the plugin IDs and compare them with the stored IDs. Only those plugin states are restored that can be found by ID.

A proof-of-concept is implemented for the inputs.tail plugin to persist the last-read position across telegraf restarts, avoiding loss of lines or rereading of the whole file.

This PR is related to #8489 but only implements part of the machinery defined there. Regarding state persistence the following differences are prominent:

1. config api #8489 has a more extensible storage API. This PR can be moved to the approach used there if we split up config api #8489.
2. config api #8489 currently does not provide a mechanism to store plugin states across telegraf runs.
3. The ID computation in config api #8489 does not survive a restart and will not be suited to persist states across restarts.

Feedback, ideas and critique welcome! :-)