WIP: new approach to efficiently hashing 1, 1.0, big(1), the same.

The major change is that numeric values that are mathematically
equal hash the same. This is tricky to do in a way that allows the
hashing of Int64, Float64, Uint64 and such common numeric types to
all be fast – nearly as fast as just applying the core hash to them
as raw bits.

Although tests pass, this is an inherently half-baked state since
isequal and hash are now badly out of sync. Many decisions still
need to be made about how to hash collections: does the collection
type matter or just the element type of the collection? Or neither?

This also does away with the bitmix function, instead favoring a
Merkle-Damgård style of combining arbitrary amounts of data into a
single, fixed-size hash value output. In a sense the hash function
with two arguments replaces the bitmix function – you can give the
result of hashing previous values as the second argument to hash
and the result will depend on both in a difficult-to-predict way.
decompose: fix documentation of decompose for rational hashing.
define hash(x) = hash(x, zero(Uint)) in a single place; fix bugs.
MathConst: == and hash
move generic rational hashing definitions into hashing2.jl
Work around LLVM's dickish undefined constant folding behavior.

LLVM's fptosi intrinsic is undefined for NaN, so LLVM obnoxiously and
pointlessly does different things when it gets NaN as a run-time value
than as a compile-time value. To avoid this shitty, pointless trap, we
have to avoid calling fptosi on NaN by introducing a branch into the
hashing function – even though for hashing, we don't care *what* value
is produced, just as long as it's consistent. Unfortunately, this
affects the performance of Float64 hashing pretty badly. I was not
able to figure out any way to recover this lost performance. LLVM
really needs to stop doing this.
generic hash(Real) optimization: remove type assert on `decompose`.

Apparently the type assertion after the decompose call was sabotaging
the ability to inline the call to decompose for Rational{Int}.
Removing the type assert gives a 10x boost, bringing the speed of
generic hash(Rational) to withing 10x of hash(Int).
More streamlined hashing for smallish rational types (≤ 64-bits).

This actually provides less gain over the generic real hashing
function than you would think, but it is slightly faster.
signbit: return a boolean value, instead of an Int.

While messing around with generic equality checking based on the
new decode function introduced in the hashing work, I discovered
that LLVM seems to be much better able to analyze expressions that
use signbit when it's boolean and explicitly defined as `x < 0` for
integer values. Since `true == 1` and `false == 0` this is a pretty
benign change, although technically it is breaking. I've wanted to
do this for a while and this seems like as good a time as any.
isnan, isinf, isfinite: improved generic definitions.

Defining isfinite in terms of decompose is simple. It seems good to
insist that only floating-point reals can be NaN – NaN in hardware
is simply an unavoidable reality. For any user-defined type that is
not implemented in hardware, NaN should not exist since operations
that would produce NaNs should raise immediate errors instead.
move hash(WeakRef) into base/hashing.jl also (not needed so early).
hashing: make new hashing work on 32-bit systems.
isequal, isless: bring comparison and sorting in line with new hashing.
`d[k] = v`: replace key when new values are assigned in dicts.

Setup:

	julia> d = Dict()
	Dict{Any,Any}()

	julia> d[1] = "foo"
	"foo"

	julia> d
	{1=>"foo"}

	julia> d[1.0] = "bar"
	"bar"

Before:

	julia> d
	{1=>"bar"}

After:

	julia> d
	{1.0=>"bar"}

The new behavior seems far less surprising to me.
Merge branch 'master' into sk/hashing

Conflicts:
	base/profile.jl
workaround for the Type{()} error
update docs for == and isequal
doc: some wording adjustments for isequal.
Add libunwind patch from Pyston
Install sigint handler for program mode too