Better plugin configuration patterns / guidelines.

[edwbuck]

The unit tests for the SPIRE built-in plugins all have some form of unit testing; but, the patterns established in the unit testing are varied:

• Some test based on a mock gRPC request struct.
• Some test based on passing a CoreConfig struct in the testing table.
• Some test based on passing a trustDomain string to be parsed and used with plugintest.CoreConfig(...)
• Some initialize the plugin in a separate block prior to being configured.
• Some combine plugin configuration into one block.

About the only item that's mostly consistent is that the plugin's config is passed as a string.

I recommend that this Issue capture the desired testing interface which would support all of the common configuration testing scenarios, facilitating a better and more consistent means of plugin configuration testing.

This should also extend into the realm of creating a simple to use Validation testing interface, so we can have a consistent plugin testing experience.

Lack of consistency in plugin testing was detected in #5303

If we keep testing more consistent between built-in plugins, it would be easier to focus on configuration permutations, option coverage, etc.