Correct license to 3-clause BSD in poms.
Clarify comment.
Remove dead target: locker.actors
Untangle classpaths related to doc targets.
Generate scaladoc for each subproject.
Continuations plugin gets its own osgi source bundle.
Inline src/build/pack.xml into build.xml.

It tended too easily to get out of synch with build.xml.
Simplify packing, align maven-deploy and pack-maven.
Support publishing to maven from main build

Publish to maven with `ant publish.local`,
`ant publish`, or `ant publish.signed`.

For now, we must keep copying `src/build/maven/maven-deploy.xml`
to `dists/maven/latest.build.xml`, along with its dependencies,
as it's used by jenkins jobs and PR validation.

TODO: `inline src/build/maven/maven-deploy.xml` into `build.xml`.
Towards minimal build for publishing core to maven.

Use `unless` attribute in targets so that `docs.skip` influences dependency graph.

Create `scaladoc` task in `pack.core` so that we don't need `pack.done`
for publishing the core.

Move source bundle creation from `dist.src` to `osgi.core`/`osgi.done`.

Split dependencies of maven publishing into core/all variants:
`osgi.core` creates osgi bundles for just lib/reflect/comp.
Targets for publishing core to maven.

`ant publish-core-signed-opt-nodocs` creates and publishes the smallest
possible set of jars (library/reflect/compiler) we can send to maven.
It uploads jars with class files and sources, but no docs
(so that we don't need to build scaladoc or any other modules).

`ant publish-core-signed-opt` is similar, but also publishes docs.

For local experimentation: `ant publish-core-local-nodocs`.
With a little bit more work, this can be used instead of `replacestarr`.
Build cleanup. Prepare for scaladoc module build.
SI-7605 Deprecate procedure syntax

This commit covers three cases:
- constructor definitions      (def this {...})
- concrete method definitions  (def foo {...})
- abstract method declarations (def foo)

The deprecation is currently hidden behind -Xfuture pending IDE support
for migrating users from procedures to methods.
Fail build on error in signed maven publish.
Tidy pom xml files.
Bundle source and class file bundling in osgi bundling.

Fix oversight in not skipping scalap's ad-hoc published docs on docs.skip.
SI-6385 Avoid bridges to identical signatures over value classes

As Paul noted in the comments to SI-6260 (from which I mined some
test cases) "there is no possible basis for conflict here":

    scala> class C[A](val a: Any) extends AnyVal
    defined class C

    scala> class B { def x[A](ca: C[A]) = () }
    defined class B

    scala> class D extends B { override def x[A](ca: C[A]) = () }
    <console>:8: error: bridge generated for member method x: [A](ca: C[A])Unit in class D
    which overrides method x: [A](ca: C[A])Unit in class B
    clashes with definition of the member itself;
    both have erased type (ca: Object)Unit
           class D extends B { override def x[A](ca: C[A]) = () }
                                            ^
What was happening?

Bridge computation compares `B#x` and `D#x` exitingErasure, which
results in comparing:

    ErasedValueType(C[A(in B#x)]) =:= ErasedValueType(C[A(in D#x)])

These types were considered distinct (on the grounds of the unique
type hash consing), even though they have the same erasure and
involve the same value class.

That triggered creation of an bridge. After post-erasure eliminates
the `ErasedValuedType`s, we find that this marvel of enginineering is
bridges `(Object)Unit` right back onto itself. The previous
resolution of SI-6385 (d435f72e5fb7fe) was a test case that confirmed
that we detected the zero-length bridge and reported it nicely, which
happened after related work in SI-6260. But we can simply avoid
creating in it in the first place.

That's what this commit does. It does so by reducing the amount
of information carried in `ErasedValueType` to the bare minimum needed
during the erasure -> posterasure transition.

We need to know:

  1. which value class wraps the value, so we can box and unbox
     as needed
  2. the erasure of the underlying value, which will replace this
     type in post-erasure.

This construction means that the bridge above computation now
compares:

   ErasedValueType(C, Any) =:= ErasedValueType(C, Any])

I have included a test to show that:

  - we don't incur any linkage or other runtime errors in the
    reported case (run/t6385.scala)
  - a similar case compiles when the signatures align
    (pos/t6260a.scala), but does *not* compile when the just
    erasures align (neg/t6260c.scala)
  - polymorphic value classes continue to erase to the instantiated
    type of the unbox: (run/t6260b.scala)
  - other cases in SI-6260 remains unsolved and indeed unsolvable
    without an overhaul of value classes: (neg/t6260b.scala)

In my travels I spotted a bug in corner case of null, asInstanceOf
and value classes, which I have described in a pending test.
Microptimization in implicit search

Avoid creating a throwaway list of parameter types.
Merge pull request #3069 from adriaanm/build-maven-publish

Rework build to allow publishing core to maven
Merge pull request #3082 from retronym/ticket/6385

SI-6385 Avoid bridges to identical signatures over value classes