Add ScalaDoc to Quasiquotes and Liftables parts of api
Address pull request feedback
SI-8251 deprecate `ListBuffer::readOnly`

This is the first step towards fixing the unexpected behavior of `ListBuffer`.

Many of `ListBuffer`'s operations are forwarded to the underlying `List`,
essentially leaking that abstraction to clients that call e.g., `toIterable`.
When the buffer changes, the `Iterable` obtained through `toIterable` will
reflect that change.

To avoid this exposure, call `toList` to obtain an immutable copy.

See also:
https://groups.google.com/d/msg/scala-internals/g_-gIWgB8Os/kWazrALbLKEJ
https://gist.github.com/paulp/9081797
SI-6455 under -Xfuture, don't rewrite .withFilter to .filter

This has been deprecated for two major releases now,
but `filter`'s still preferred over `withFilter` in the wild.
SI-6455 util.Try supports withFilter
Merge pull request #3566 from adriaanm/t6455

SI-6455 no longer rewrite .withFilter to .filter
SI-8240 Consider rolling back optimizations for List

Some compiler-specific optimizations turn out to be very helpful for Lists in general.

  * List map can be a lot faster (up to 5x!)
  * List collect can be considerably faster (up to 3x)
  * List flatMap can be a bit faster (2x)
  * List take can be slightly faster (1.1x) and have better structural sharing

These appear to be unqualified wins (tested), even in a scenario with mixed collections.  This is expected: detecting the builder is faster than the otherwise mandatory object creation, and multiple dispatch is mostly a wash since it was already multiple dispatch in getting to the builder.

With -optimize, map is not always such a big win, but is never slower.

Also added @noinline to map to work around an optimizer bug (SI-8334) and added a test to check that the pattern that triggers the optimizer bug does not affect any of the map-like methods.
Merge pull request #3582 from adriaanm/t8251

SI-8251 deprecate `ListBuffer::readOnly`
Merge pull request #3579 from densh/topic/quasiquotes-scaladoc

Add ScalaDoc to Quasiquotes and Liftables parts of api
SI-3235 math.round() returns wrong results for Int and Long

Minimal fix for SI-3235.

This minimal fix includes deprecation messages to aid detection of probable errors.

Test verifies behavior: the correct values are returned, and deprecation messages are emitted.
Merge pull request #3498 from Ichoran/issue/8240

SI-8240 Consider rolling back optimizations for List
SI-8197 clarify overloading resolution with default args

This commit was co-authored with Lukas. His analysis is below.

If there are multiple applicable alternatives, drop those
that use default arguments. This is done indirectly by
checking applicability based on arity.

TODO: this `namesMatch` business is not spec'ed, and is
the wrong fix for SI-4592. We should instead clarify what
the spec means by "typing each argument with an undefined expected type".

What does typing a named argument entail when we don't know what
the valid parameter names are? (Since we're doing overload resolution,
there are multiple alternatives that can define different names.)

Luckily, the next step checks applicability to the individual alternatives,
so it knows whether an assignment is:
 - a valid named argument
 - a well-typed assignment (which doesn't necessarily have type `Unit`!)
 - an error (e.g., rhs does not refer to a variable)

I propose the following solution (as a TODO):
check whether a named argument (when typing it in `doTypedApply`)
could be interpreted as an assign; `infer.checkNames` should use
the type of the well-typed assignment instead of `Unit`.

Lukas's analysis:

990fa04 misunderstood the spec of overloading resolution with
defaults. it should not discard applicable alternatives that define
defaults, but only those that use defaults in the given invocation.

bugs were shadowed because the refactoring used `alt.hasDefault` to
check whether the alternative has some parameters with defaults, but
this never worked.

d5bb19f fixed that part by checking the flags of parameters, which
fixed some but but un-shadowed others:

```
object t { def f(x: String = "") = 1; def f(x: Object) = 2 }
scala> t.f("") // should return 1, but returns 2 after d5bb19f
```

The commit message of d5bb19f also mentions that its test "should
fail to compile according to SI-4728", which is another
misunderstanding.

```
class A; class B extends A
object t { def f(x: A = null) = 1; def f(x: B*) = 2 }
t.f()
```

This should return `2`: both alternatives are applicable, so the one
that uses a default is eliminated, and we're left with the vararg one.
SI-4728 is different in that it uses explicit parameters,
`t.f(new B)` is ambiguous.
Merge pull request #3581 from Ichoran/issue/3235-minimal

SI-3235 math.round() returns wrong results for Int and Long
Merge pull request #3583 from adriaanm/t8197

SI-8197 clarify overloading resolution with default args
SI-4728 test case
Merge pull request #3585 from lrytz/t4728

SI-4728 test case
Selectively revert "SI-8315 Better debugging facility for ICode"

This reverts commit 0561dd084b5f3c2678eb032a40b85cb25bb6d589,
because appending the phase name to the icode filename breaks
the windows build. Only doing it under -Ydebug.
Merge pull request #3586 from adriaanm/windows-opt-fail-revert

Revert "SI-8315 Better debugging facility for ICode"