SI-8170 Fix regression in TypeRef#transform w. PolyTypes

Regressed in SI-8046 / edc9edb7, by my hand.

At the time, I noticed the problem: transform wasn't accounting
for the potential Poly-Type-ness of its argument, and this would
lead to under-substituted types. The commit comment of edc9edb7
shows an example.

But the remedy wasn't the right one. The root problem is
that a TypeMap over a PolyType can return one with cloned
type parameter symbols, which means we've lose the ability
to substitute the type arguments into the result.

This commit detects up front whether the type-under-transform
is a PolyType with the current TypeRef's type parameters, and
just runs the `asSeenFrom` over its result type.
Improve ExecutionContext implicitNotFound and docs

It is not good practice to import a specific ExecutionContext
all over the place; we shouldn't recommend that. People should
allow callers to specify the context in most cases and only
import the context in some central location in their code.

While we are at it, add some more comprehensive docs to
ExecutionContext which will hopefully give people enough understanding
to make decisions about it.
SI-4997 deprecate StringLike.linesIterator for StringLike.lines

Deprecated.  lines is by far more consistent with the rest of the naming in the library.
SI-8228 Avoid infinite loop with erroneous code, overloading

`isApplicableBasedOnArity` couldn't get of the ferris wheel after
as `followApply` kept insisting on another spin.

    scala> ErrorType nonPrivateMember nme.apply
    res0: $r.intp.global.Symbol = value apply

    scala> res0.info
    res1: $r.intp.global.Type = <error>

This commit makes `followApply` consider that an `ErrorType`
does not contain an `apply` member.

I also considered whether to do a deep check on the type
(`isErroneous`), but I can't motivate this with a test.
I tend to think we *shouldn't* do that: `List[${ErrorType}]`
still has an `apply` member that we should follow, right?
SI-8233 Fix regression in backend with boxed nulls

Regressed in SI-7015 / 1b6661b8.

We do need to "unbox" the null (ie, drop a stack from and load
a null) in general. The only time we can avoid this is if the
tree we are adapting is a `Constant(Literal(null))`.

I've added a test for both backends. Only GenICode exhibited
the problem.
PR #3233 cleanup

- `::.head` became a `val`; excessive accessor removed
- SerializationProxy moved to `object List`
SI-8170 Posing outstanding questions as TODOs

We'll get to the bottom of this as soon as we get
one of those Round Tuits.
Merge pull request #3465 from pavelpavlov/list-head-val

PR #3233 cleanup
Merge pull request #3400 from retronym/ticket/8170

SI-8170 Fix regression in TypeRef#transform w. PolyTypes
Merge pull request #3462 from retronym/ticket/8233

SI-8233 Fix regression in backend with boxed nulls
Merge pull request #3453 from Ichoran/issue/4997

SI-4997 deprecate StringLike.linesIterator for StringLike.lines
Merge pull request #3432 from havocp/patch-1

Improve ExecutionContext implicitNotFound and docs
Merge pull request #3457 from retronym/ticket/8228

SI-8228 Avoid infinite loop with erroneous code, overloading
Fix compilation errors

This fixes compilation errors about adapted argument lists and
a type error between CharSequence and String