Migrate processor to the new global registry

[ph]

depends on #7392

[houndci-bot]

exported type Constructor should have comment or be unexported

[houndci-bot]

exported function Plugin should have comment or be unexported

[ruflin]

Is this variable here used for something?

[ph]

Yes this is used by the global registry, see comment #7392 (comment) for a bit more details about the usage.

[urso]

A little sad the Namespaces are gone from processors. Namespaces allow plugins to be further namespaced (used in x-exec branch). E.g. have common namespaces for common plugin types.

The way it was used:

processors:
- lookup.exec:
    ...

- lookup.file:
    ...

The Namespace ensured lookup is a namespaced feature/plugin with it's own set of plugins. I wonder if we want to re-introduce this functionality with outlook of turning metricbeat/filebeat modules into features as well.

[ph]

@urso I think this can still be done with a flat structure and handled at the processor level instead.
If I look at your comments the "lookup" processor will have 2 plugins: file and exec.

in a flat view the namespace will be "libbeat.processor.lookup", so when we create the processor "lookup", he can create the exec or file. We cannot assume that exec or file actually implements the processor interface it could be something else, like in the add_kubernetes_metadata processor.

But, we can provide code to wrap a nested processor.

[ph]

Another way to look at it, is `lookup' is a bundle of two features file and exec.

[ph]

@urso I've moved the code to use feature.NewDetails and rebased the code, all the "actions" processors expose a Bundle that we can register in the include package. All the other processors expose a unique feature.

This is ready for review and be merged into the feature branch.