Filter documentation could be better

The current documentation is hard to use, and makes assumptions about what it is for.

This is normally used to separate out the contents of an artifact into multiple artifacts and define separate sets of dependencies, in cases where a build produces multiple discrete “packages”, e.g. systemd and udev; gettext and libintl.

I think that coming up with the above use case is an exercise better left to the user, otherwise it is clouding the useful documentation of how to actually use the plugin, which I find lacking.

This element expects precisely one build dependency, and multiple runtime dependencies that are not the element that was the build dependency.

The above is the important part; but still fails to express how to use the plugin, and what happens with the runtime dependencies.

Nowhere is it mentioned that the element which is a build dependency is the one which is filtered.

It would be better to mention that a single build dependency must be set, and it is the one that will be filtered.

Separately, it would be better to mention that runtime dependencies can be expressed, and as such they will be propagated forward as dependencies of elements which depend on the filter element.