Don’t catch `AssertionError` in `getOption`

This caused some tests to fail under the radar, since JUnit asserts were silently logged
and not rethrown. This brings the test suite back to normal and fixes the tests that
were actually failing.
Turn off auto-building, hopefully this makes the test less flaky.
Restore correct selection when region changed at end of selection

Fixes #1002314
Merge pull request #843 from dragos/issue/missed-tests

Don’t catch `AssertionError` in `getOption`
Merge pull request #844 from sschaef/selection-lost

Restore correct selection when region changed at end of selection
Show @return in scaladoc hovers

Fixes #1002312
Merge pull request #841 from mlangc/master

Show @return in scaladoc hovers
Revert "Interrupt Scala builder on resource change"
Create a build marker when a project is not built due to upstream errors.

Fixed #1002320
Merge pull request #845 from scala-ide/revert-767-t1002229-interrupt-build

Revert "Interrupt Scala builder on resource change"
Merge pull request #846 from dragos/issue/no-build-markers-downstream

Create a build marker when a project is not built due to upstream errors...
Avoid spurious typer cycles / "no progress completing" errors

Scala IDE is currently experiencing spurious
cyclic and "no progress in completing" errors.

I attached a debugger to the IDE to try to catch it in the act.
I've recorded my findings and hypothesis in more detail in
https://www.assembla.com/spaces/scala-ide/tickets/1002325#

I managed to craft a test that demonstrates this. The test is
not included here, but in a branch in my scala repo.

https://github.com/retronym/scala/commit/2e75c7596558df4c9de2526246b5a65da018300b

In that, I have reproduced a scenario that matches
this hypothesis. In the first run, we stop shortly after running
the namer over a top level module. I've rigged up the test to then
create a new run, and then force the info of that module. This
triggers typechecking of that module's contents, which includes
a nested case class.

When entering a case class symbol, the namer needs to checks if there
is a user written companion object beside it. If not, a synthetic
companion must be created.

There is a tension in play in this lookup. If we are searching for
the companion of a member symbol from sources, we must not force the
owner's info prematurely, but rather be prepared to check the scope
in an enclosing `Context` to find the sibling symbol. Conversely,
if we are looking up the companion of a nested symbol sourced from
a class file, we must be careful to force the owner's info before
inspecting its members (SI-7264).

The mechanism to resolve this tension in `Namers#companionSymbolOf`
is predicated on whether or not the owner is compiled by the current
run.

This commit overrides `companionSymbolOf` changes the condition from
being run based to instead peeking at whether the owner has an source
`TypeCompleter` as its incomplete info.

I will roll this change into the presentation compiler proper
after we get some experience with the fix in the IDE.
Merge pull request #849 from retronym/ticket/1002325

Avoid spurious typer cycles / "no progress completing" errors