Move built-in detectors to their own plugin

[sewe]

This is probably a suggestion for SpotBugs > 3.1.0, but it would IMHO be nice to move the built-in detectors to their own plugin (say edu.umd.cs.findbugs.plugins.detect), with edu.umd.cs.findbugs.plugins.core providing only the SpotBugs infrastructure.

This would allow users to easily switch off all built-in detectors (if they want to rely solely on a third-party detector plugin):

 bin/fb analyze -choosePlugins +edu.umd.cs.findbugs.plugins.core …

At the moment, this fails with the message

Can't disable core plugin

This leaves the user only the option to explicitly enumerate all built-in detectors using -omitVisitors or -chooseVisitors.

Aside from this use case, I think moving the built-in detectors into their own plugin would provide a more general benefit: It puts SpotBugs’ plugin architecture and package organization to the test in the SpotBugs project itself. At the moment, SpotBugs relies on projects like fb-contrib to report any restrictions due to the silent assumption that all detectors are equal, but some detectors are more equal than others.

WDYT?

[h3xstream]

This would also help Unit testing of plugin ..

By default SpotBugs autoload the core rules, from the classpath (/findbugs.xml). This force plugin like FSB to place metadata files to a dummy resource folder to avoid core not properly load and breaking SpotBugs startup.

I am refering to this hack: https://github.com/find-sec-bugs/find-sec-bugs/blob/master/plugin/pom.xml#L26
Which introduce few side-effects building the solutation.

[KengoTODA]

@h3xstream I think SpotBugs now doesn't need this hack, #22 solved it.
I confirmed this fix in my plugin: KengoTODA/findbugs-slf4j@ad9c2d9