…call(f, x...) as a fallback (if f is not a function); to do: update inference, fallback to call when f is a type

Conflicts:
	src/codegen.cpp
	test/core.jl

Conflicts:
	base/base.jl
	test/core.jl

- look up call in the right module instead of using jl_call_func
- some inference support for call overloading
- pass `call` to _apply and kwcall so they use the containing module's definition
- deprecate explicit apply(), rename the builtin to _apply

Conflicts:
	base/deprecated.jl
	base/inference.jl

this does not work yet, but gets past the first bootstrap stage.

so far this is a significant net simplification.

REPL now works with sys0.ji

…pes in Base

this allows the full build to go through

… generated `call` methods

- make typeintersect((Rational{T},T),(Rational{Integer},Int)) == (Rational{Integer},Int)
  This used to be Bottom, since the T's had to match exactly. Now if T
  appears in covariant position, subtypes can also match. This is a
  good change anyway, but turns out to be necessary for the new constructor
  design. We have a constructor `Rational{T}(x::T, y::T)` which now gets
  lowered to `call{T}(::Type{Rational{T}}, x::T, y::T)`, so obviously we
  must allow x and y to be any subtypes of T.
  This also allows convert_default to be replaced with
  `convert{T}(::Type{T}, x::T) = x` (to be done next).

- making that work required an improved constraint solving algorithm in
  type intersection. the new algorithm should be much more robust, but
  it yields more typevars in its answers, for example
  `typeintersect((T,AbstractArray{T}),(Any,Array{Number,1}))` gives
  `(_<:Number,Array{Number,1})`.

  Hopefully this will not cause problems. But I can imagine doing a
  post-processing step to replace `_<:T` in covariant position with
  just `T`. In the meantime, to further legitimize such results I
  also made the next change:

- make TypeVar a subtype of Type

…ng convert_default

another Core.convert method to prevent types from old Base from leaking in

…tructors

Conflicts:
	src/codegen.cpp

fix `TypeVar` dispatch

also *require* it for `new` calls inside non-constructors

…tructors

…tructors

change a comprehension in Pkg.Reqs.Requirement that depended on type
inference. due to `call` constructors we simply cannot get its type
anymore, although the other change in this commit helps a lot.

…finition, since the method will actually be added to `call`

this is not ideal but will give us more flexibility for now

…tructors

the subtype check in gf.c:ml_matches (line 1834) was causing an extra
matching method to be missed, when we have both call(::Type{Perm},...)
and call(::Type{Perm{O,V}},...)

…tructors

Conflicts:
	src/julia-syntax.scm

I put `::T` on there for now; we'll see how that goes.

…ts the same type repeatedly

…all_constructors

Conflicts:
	src/builtins.c
	src/dump.c