Better pattern matcher error message.

For the common case when someone hasn't quite grokked
the significance of lower case in a pattern match.  I'd
like to make all the unreachables errors, not warnings,
but there may be a bug or two to clear out first.

class A {
  def badEquals(x: Any, y: Any) = x match {
    case y => true
    case _ => false
  }
}

a.scala:3: warning: patterns after a variable pattern cannot match (SLS 8.1.1)
If you intended to match against parameter y of method badEquals, you must use backticks, like: case `y` =>
    case y => true
         ^
a.scala:4: warning: unreachable code due to variable pattern 'y' on line 3
    case _ => false
              ^
two warnings found
Renamed elem to head and next to tail

both head and tail are now O(1) with very low overhead like you would expect for a list-like data structure
Create a HashSet1 in case ks1 contains just one entry

Create HashSetCollision1 only if there is more than one element
SI-6184 don't introduce dummies in checkableType

this should fix the crash in asSeenFrom that resulted from calling
baseTypeSeq on a type that had an unbound type parameter in it

also, simplify widenToClass
SI-6022 refactor to clean up model of variable equality modulo <:

this commit does a functionality-preserving refactoring
SI-6022 cleaner model of variable equality modulo <:

a more conservative "excludes": no need to reason about types

(TODO: check we don't get any spurious unreachability errors
 in the eclipse build, which is a good canary for this kind of thing)
Support per-group flags files in partest

In a directory-based test with file A_1.scala, scalac flags that should apply only to A_1.scala can be put in the file A_1.flags. Local flags are appended to global flags.
SI-6119 Fix mispelling on take documentation.
Only create a HashTrieSet if necessary.

If allow HashTrieSets with one element, you can get a degenerate tree that is six levels deep yet contains only one element by first building a large tree and then removing elements
Removed hot statistics call in normal path.

Some calls to Statistics  are now subject to the compile-time constant hotEnabled, which means they will be eliminated entirely in the default case where hotEnabled = false.
Ensure that a.merged(b)(null) always chooses a in case of collisions

Moved definition of liftMerger to companion object and replaced null with a default merger so merge works predictably if you pass null as a merger. Maybe we should just not allow null as a merge function at all.
refines api.FlagSets

In the current vision of flags, they should only be used to construct trees,
because tests are subsumed by the numerous isXXX methods that we have.

Hence we need to remove `hasFlag` and the flags that don't make sense being
added to tree modifiers manually.

A good example of that is MODULE. There's an isModule check, so hasFlag MODULE
is redundant. On the other hand, you don't need MODULE to construct a ModuleDef
so it's redundant in this department as well.
some more copyright cleanup for 2012

contributed by Carlo Dapor -- thanks!
Merge pull request #1091 from paulp/topic/patmat-error-messages

Better pattern matcher error message.
Merge pull request #1103 from dcsobral/si/6119bp

SI-6119 Fix mispelling on take documentation. (backport)
Merge pull request #1113 from adriaanm/copyright

some more copyright cleanup for 2012
Merge pull request #1108 from rklaehn/SI-5879

Ensure that a.merged(b)(null) always chooses a in case of collisions
Merge pull request #1111 from scalamacros/ticket/6212

refines api.FlagSets
a follow up on e01ec05a1e

Removes all traces of flags from symbol API, adds general flag set (hasFlag)
to Modifiers (because Modifiers don't have isXXX checks that symbols have).

This also removes macros.Symbol.setFlags, because taking into account current
state of affairs that method was at best incomplete.
SI-6201 minor fixes in key points

Fixes several oversights that led to 6201. RootPackage should have been static,
refactored implementation of hasSymbolWhich shouldn't have checked hasSymbol.

Full discussion is here:
http://groups.google.com/group/scala-internals/browse_thread/thread/9500348f273a8aa.