Remove context classloader from SPI lookups by default

As discussed on LUCENE-7870, we should really remove the context class loader from Lucene's SPI lookup (NamedSPLoader, SPIClassIterator, AnalysisSPI stuff).

My idea would be (as stated before): Get rid of the Context Classloader in SPI lookups! Lucene never uses it, it is just there for backwards compatibility. The current setup of SPI does not work with modules of Java 9 and it does not work with stuff in completely different classloaders. So OSGI fails in any case, if you have lucene-core.jar and lucene-backwards-codecs.jar as OSGI modules, because both would use different loaders. The context loader won't help.

The problem is that we may break some apps that rely on the context loader traversal. In my opinion, we may add a system property that is read on setup of NamedSPILoader / SPIClassIterator that can be set to true (e.g. lucene.useContextLoaderForSPI, defaulting to false). This may fix legacy apps and new apps would only traverse the classloader that loaded lucene-core.jar.

For Java 9 and "Lucene as Java 9 module") we have to refactor this anyways, becaue we need to respect module-info,java and look for SPI exports.

FYI: Context class loaders were the worst idea ever in Java. I personally hate them and I would do anything - just to make them disappear from the spec! When drinking beers with Mark Reinhold in Brussels, I am always reminding him about this together with the inability to unmap byte buffers...

Unfortunately the sysprop approach is the only way to handle this as this must be done very early on JVM/Lucene setup. If somebody called Codec.forName() its too late to change the default... But I am fine with using a sysprop with AccessController.doPrivileged(), as this is only required for those legacy WEBAPP stuff. Normal applications should see the META-INF files on the application classloader anyways.