plugins: Do not require a "type" subfolder hierarchy

The folder structure was introduced to organize the plugins and permit more efficient loading during the startup but the gains are slight and the requirement is awkward to describe and easy to forget in practice.

Remove that requirement and load any compatible binary plugin in the plugin folder. This also allows extra flexibility to organize the plugins in categories, for example adding an "external" folder for plugins external to the project, or whatever else one might wish.

To check for library compatibility we add an extra string signature token in the plugin that can be compared with the expected plugin type.

The downside is that the initialization is still performed 3 times and more files need to be skipped now but in practice this should not have a measurable performance impact (untested) and this eliminates a class of annoying small forgetful mistakes when manually installing files.

This is still compatible with the old requirement of having a epan/wiretap/codecs subfolder. At most one sublevel is allowed to minimize security risks and slowness with any random folder hierarchies if the plugins folder setting is somehow misconfigured or hijacked.

Ping #19389 (closed).