SI-5639 Fix spurious discarding of implicit import

In Scala fa0cdc7b (just before 2.9.0), a regression in implicit
search, SI-2866, was discovered by Lift and fixed. The nature of
the regression was that an in-scope, non-implicit symbol failed to
shadow an eponymous implicit import.

The fix for this introduced `isQualifyingImplicit` which discards
in-scope implicits when the current `Context`'s scope contains
a name-clashing entry.

Incidentally, this proved to be a shallow solution, and we later
improved shadowing detection in SI-4270 / 9129cfe9. That picked
up cases where a locally defined symbol in an intervening scope
shadowed an implicit.

This commit includes the test case from the comments of SI-2866.
Part of it is tested as a neg test (to test reporting of ambiguities),
and the rest is tested in a run test (to test which implicits are
picked.)

However, in the test case of SI-5639, we see that the scope lookup
performend by `isQualifyingImplicit` is fooled by a "ghost" module
symbol. The apparition I'm referring to is entered when
`initializeFromClassPath` / `enterClassAndModule` encounters
a class file named 'Baz.class', and speculatively enters _both_ a
class and module symbol. AFAIK, this is done to defer parsing the
class file to determine what inside. If it happens to be a Java
compiled class, the module symbol is needed to house the static
members.

This commit adds a condition that `Symbol#exists` which shines a torch
(forces the info) in the direction of the ghost module symbol. In our
test, this causes it to vanish, as we only need a class symbol for
the Scala defined `class Baz`.

The existing `pos` test for this actually did not exercise the bug,
separate compilation is required. It was originally checked in to
`pending` with this error, and then later moved to `pos` when someone
noticed it was not failing.
SI-8253 Fix incorrect parsing of <elem xmlns={f("a")}/>

The spliced application was placed in the `attrMap` in
`SymbolicXMLBuilder` and later incorrectly matched by a pattern
intended only to match:

    xml.Text(s)

That attribute value is generated by parsing:

   <elem xmlns='a'/>

So the net effect was that the two fragments of XML were identical!

This commit sharpens up the match to really look for a syntactic
`_root_.scala.xml.Text("...")`.

The test just prints the parse trees of a variety of cases, as we
we should not test the modularized XML library in scala/scala.
SI-7444 docs: null Executor allowed in ExecutionContext factories

Update the ScalaDoc for the factory methods for `ExecutionContext`
which allow a `null` `Executor`/`ExecutorService`.
SI-5639 Predicate bug fix on -Xsource:2.12

To be conservative, I've predicated this fix in `-Xsource:2.12`.
This is done in separate commit to show that the previous fix
passes the test suite, rather than just tests with `-Xsource:2.12`.
Merge pull request #4118 from retronym/ticket/5639

SI-5639 Fix spurious discarding of implicit import
Merge pull request #4132 from phaller/ticket/7444

SI-7444 docs: null Executor allowed in ExecutionContext factories
Merge pull request #4123 from retronym/ticket/8253

SI-8253 Fix incorrect parsing of <elem xmlns={f("a")}/>
Introduce Flags.ANNOTATION
SI-8928 Read Java annotations in Java source files