SPI shouldn't expose impl types

Resolved as part of the Search 6 proof of concept groundwork.
We also set up tooling to prevent this from happening again in the future ()

You can also use the jQAssistant set-up we're having in HV to detect these inconsistencies: http://in.relation.to/2017/01/31/preventing-leaky-apis-with-jqassistant/.

Note that build logs seem to actually highlight those problems:

Noticed while working on

> Is AbstractDocumentBuilder actually an SPI type, i.e. are we expecting others to extend it and build their own document builder types

Not in my world, but might know more

> Regarding the getter, if it is not intended to be used by integrators, who is the intended user then? Maybe it just could be removed? Or if required internally, moved to an internally-used extension of AbstractDocumentBuilder?

It is for internal use.

Is AbstractDocumentBuilder actually an SPI type, i.e. are we expecting others to extend it and build their own document builder types (given all the types in *.spi it may be though that I'm having another definition of "SPI" in mind than the one used here)?

Regarding the getter, if it is not intended to be used by integrators, who is the intended user then? Maybe it just could be removed? Or if required internally, moved to an internally-used extension of AbstractDocumentBuilder?

Should we ever want to OSGi-ify SEARCH (or restrict the public packages of the JBoss module) such leakage of non-exported types via public signatures would cause some trouble.