[WIP] Port of DOP853

This is an almost complete port of DOP853 (the dense output functionality is still missing) with quite good performance (https://groups.google.com/forum/#!searchin/julia-users/dop853/julia-users/41B3qULjF-0/WqGa-Lc04AkJ), approximately 2-3x slower than Fortran (without compiler optimizations) for longer runs. Since the 5-th order version DOPRI5 looks rather similar implementing it as well should not be a huge amount of work

See also: #25

To Do:
* [ ] API adjustment
* [ ] Dense output
* [X] DOPRI5
* [X] Write tests
* [ ] Documentation

* What else?
* Is it a good idea to separate different solver families in different source files?
Thanks for actually showing some code that uses this pattern! I hope you enjoy my comments, and that you don't hesitate to ask, if you think I might say something wrong or confusing.

I understand why you have `[]` arround `p.f(x, t)`, but I don't like it, and hope it will prove unnecessary to restrict (convert) `y` to mutable.

Currently we really want to reuse arrays if we can, because GC and allocation is painfully slow in Julia at the moment. We also want to allow the interface to allow users to avoid anonymous functions because they are slow. AFAIKS the algorithm does not care about reuse, and `F!` could decide to return a new array, if that is easiest. The requirement would be that the invocation of `F!` was on the form:
```julia
y = F!(p, y, x, t)
```

We might also want to have a default implementation for `F!` that calls `F` but implicitly discards `y`, so that you could implement either `F!` or `F` to specify a problem.
```julia
F!(p::ODEProblem, y, x, t) = F(p, x, t)
```

PS. these definitions `ODEProblem(Function)`, `F!` and `F` will (when we manage to figure out how they should work) be part of the general API of ODE.jl, so they should be placed in a `src/api.jl` file, instead of in a specific solver's file.