SI-6061 adds weakly conformance for number types to resolveOverloaded

This fix changes resolveOverloaded in scala.reflect.internal
so that numeric widening on the actual argument types is also
considered for primitive number types. Needs changes in functions
applicable and mostSpecific.
Fix Scala library dependency in Eclipse project files.

Remove dependency on Scala library shipped with Scala IDE.
In compiler projects we depend on library project itself so there's
we shouldn't duplicate library dependency.

Review by @dragos.
Add `partest` and `scalap` Eclipse project definitions.

Created by copying scala-compiler project
definition and manually editing project files
so they point at partest and scalap. I imported it
successfully to Eclipse.

Review by @dragos.
Fixed SI-6076. Range positions for macro-based string interpolation.
Should bring back the jenkins job as well.

Review by @odersky.
fixes a typo in macro classloaders

Primary should be here, because a test a few lines up checks whether
primary != "". Hence usage of fallback here is just a typo.

Primary and fallback classpaths were designed for situations when library
classpath are not enough (e.g. for bootstrapping libraries that don't get
onto tool classpaths). Originally I planned to use them to bootstrap
scala-library, however, there's always a starr/locker on a tool classpath,
so we don't need special treatment of this case. After I realized that, I
decided to keep advanced classpath switches, because others might not be as
lucky as we are.
move test files that fail spuriously to pending

I have this sneaky suspicion that part of these spurious failures
are caused by the recent partest optimizations.

@axel22 already checked that compiler instances are not shared between test runs.
However, except for the benchmark test, they all have a distinct
race condition in symbol loading/type checking feel to them.

Since, in the end, the tests and/or their corresponding fixes are as likely
a culprit as the test framework, moving them out of the way until their owners
can get them back in line and they stop throwing primate wenches into our build.

We should bring them back as soon as possible, though.
uses weak_<:< from Types to solve this issue
Fixes SI-5588. Correct compare for Enumeration.
Slower than the original one but does comparison in the same spirit as IntOrdering.

Review by @axel22.
SI-5731 a few fixes for value classes

I've faced two gotchas.

First of all posterasure, which is supposed to erase ErasedValueType types,
didn't look into ConstantType.value that is known to be smuggling types
(hi Paul that's a plus one).

Secondly ClassManifest.classType[T] assumed that its T is bound by AnyRef,
which is not the case for value types. Here I had two choices:
a) introduce a special method for manifests of value types,
b) remove the upper bound of the type parameter and call it a day.
Since manifests are already deprecated and there's no difference which
method was used to create which manifest, I went for option b).
Merge pull request #916 from gkossakowski/eclipse-project

Eclipse project updates
Merge pull request #932 from hubertp/2.10.x-issue/5588

Fixes SI-5588. Correct compare for Enumeration.
Merge pull request #928 from hubertp/2.10.x-issue/6076

Fixed SI-6076. Range positions for macro-based string interpolation.
Merge pull request #933 from scalamacros/ticket/5731

SI-5731 a few fixes for value classes
Merge pull request #921 from adriaanm/ticket-spuriousness

move test files that fail spuriously to pending
Merge pull request #883 from dgruntz/issue/6061

SI-6061 adds weakly conformance for number types to resolveOverloaded
Merge pull request #926 from scalamacros/topic/macro-classpaths

fixes a typo in macro classloaders
Implement @static annotation on singleton object fields.

This commit introduces the `@static` annotation on fields of static singleton objects.

A static singleton object is a top-level singleton object or an object nested within
a static singleton object.

The field annotated with `@static` is generated as a true static field in the companion
class of the object. The initialization of the field is done in the static initializer of the
companion class, instead of the object itself.

Here's an example. This:

    object Foo {
      @static val FIELD = 123
    }
    class Foo

generates :

   object Foo {
     def FIELD(): Int = Foo.FIELD
   }
   class Foo {
     <static> val FIELD = 123
   }

The accessor in `object Foo` is changed to return the static
field in `class Foo` (the companion class is generated if it is
not already present, and the same is done for getters if `FIELD`
is a `var`).

Furthermore, all the callsites to accessor `Foo.FIELD` are rewritten
to access the static field directly.

It is illegal to annotate a field in the singleton object as `@static` if there is
already a member of the same name in `class Foo`.

This allows better Java interoperability with frameworks which rely on static fields being
present in the class.
The `AtomicReferenceFieldUpdater`s are one such example. Instead of having
a Java base class holding the `volatile` mutable field `f` and a static field containing
a reference to the `AtomicReferenceFieldUpdater` that mutates `f` atomically,
and extending this Java base class from Scala, we can now simply do:

    object Foo {
      @static val arfu = AtomicReferenceUpdater.newUpdater(
        classOf[Foo], classOf[String], "f"
      )
    }
    class Foo {
      @volatile var f = null
      import Foo._
      def CAS(ov: String, nv: String) = arfu.compareAndSet(this, null, "")
    }

In summary, this commit introduces the following:
- adds the `@static` annotation
- for objects without a companion class and `@static` members, creates a companion class
(this is done in `CleanUp`)
- checks for conflicting names and if `@static` is used on static singleton object member
- creates the `static` field in the companion class for `@static` members
- moves the field initialization from the companion object to the static initializer of
the class (the initialization of `@static` members is bypassed in the `Constructors` phase,
and added to static ctors in `CleanUp`)
- all callsites to the accessors of `@static` are rewritten to access the static fields directly
(this is done in `GenICode`)
- getters and setters to `@static` fields access the static field directly, and the field in the
singleton object is not emitted (this is done in `GenICode`)
- changes in `GenJVM`, `GenASM` - now computing local var indices in static initializers
as well - this was an oversight before, now is necessary

Future work: allow the `@static` annotation on methods as well - this will
be added in a future commit.

Review by @odersky, @dragos, @paulp, @heathermiller.