SI-6331 Avoid typing an If tree with a constant type.

The fast path in typedIf added in 8552740b avoided lubbing the if/else branch types
if they are identical, but this fails to deconst the type. This could lead to the entire
if expression being replaced by a constant.

Also introduces a new tool in partest for nicer checkfiles.

// in Test.scala
trace(if (t) -0d else 0d)

// in Test.check
trace> if (Test.this.t)
  -0.0
else
  0.0
res: Double = -0.0
Refine equality of Constant types over floating point values.

The constant types for 0d and -0d should not be equal.

This is implemented by checking equality of the result of
doubleToRawLongBits / floatToRawIntBits, which also correctly
considers two NaNs of the same flavour to be equal.

Followup to SI-6331.
Test for consistency of Constant#{equals, hashCode}.

For the examples I've constructed, they are consistent, but
I put this down to good luck, rather than good management.
The next commit will address this.
Improve Constant#hashCode

 - Incorporate `tag`, which is considered by equals, to reduce collisions.
 - Use the result of floatToRawIntBits(value) / doubleToRawLongBits(value),
    rather than value. This wasn't strictly necessary as (0d.## == (-0d).##)
    but this is more obviously correct.
Made 'def clone()' consistent with parens everywhere.

For the reference of others,

  ack --files-with-matches 'def clone[:\s]' src

is how you might find out who needs fixing.
Fix SI-4813 - Clone doesn't work on LinkedList.

* Added extensive test for clone across all standard mutable collections
* Fixed clone implementations when needed so they work.
Merge pull request #1281 from jsuereth/fix/SI-4813

Fix SI-4813 - Clone doesn't work on LinkedList.
Merge pull request #1301 from paulp/clone-parens

Made 'def clone()' consistent with parens everywhere.
Merge pull request #1271 from retronym/ticket/6331

SI-6331 deconst If type / refine equality of floating point Constant types.
"Hot fix" for broken build.

Two pull requests crossed in the night.
Eliminate breaking relative names in source.

These things are killing me.  Constructions like

  package scala.foo.bar.baz
  import foo.Other

DO NOT WORK in general.  Such files are not really in the
"scala" package, because it is not declared

  package scala
  package foo.bar.baz

And there is a second problem: using a relative path name means
compilation will fail in the presence of a directory of the same
name, e.g.

  % mkdir reflect
  % scalac src/reflect/scala/reflect/internal/util/Position.scala
  src/reflect/scala/reflect/internal/util/Position.scala:9: error:
    object ClassTag is not a member of package reflect
  import reflect.ClassTag
         ^
  src/reflect/scala/reflect/internal/util/Position.scala:10: error:
    object base is not a member of package reflect
  import reflect.base.Attachments
                 ^

As a rule, do not use relative package paths unless you have
explicitly imported the path to which you think you are relative.
Better yet, don't use them at all. Unfortunately they mostly work
because scala variously thinks everything scala.* is in the scala
package and/or because you usually aren't bootstrapping and it
falls through to an existing version of the class already on the
classpath.

Making the paths explicit is not a complete solution -
in particular, we remain enormously vulnerable to any directory
or package called "scala" which isn't ours - but it greatly
limts the severity of the problem.
Merge pull request #1303 from paulp/210-relative-names

Eliminate breaking relative names in source.