Ditch some REQUIREments?

[mauro3]

If the units-test do their work properly, then we can remove Parameter.jl and Ranges.jl. I don't know how easily RecursiveArrayTools.jl could be removed. We're stuck with SimpleTraits.jl and RecipesBase.jl. Although the latter could be moved to a plots-package (but I'd rather not).

Ref: luchr/ODEInterface.jl#9

[ChrisRackauckas]

@yES, Parameters.jl is no longer used (it was used in the algorithms, now it's not).

Ranges.jl only shows up here:

https://github.com/JuliaDiffEq/DiffEqBase.jl/blob/master/src/solutions/solution_interface.jl#L55

So only when plotting a solution which has dense output, something the units tests don't cover. We can hardcode a solution. The fact is the Ranges.linspace should be the real linspace in Base because the Base linspace is not compatible with a lot of types, while the Ranges.jl version is.

To drop RecursiveArrayTools.jl, we could move the two vecvecapply methods to DiffEqBase (dup them).

But I don't know how much this really helps. This is only looking at "the number" of dependencies. In reality, if someone is just caring about the number of dependencies, they probably just care about 0 vs any. The dependencies we're talking about here are deps with either under 100 lines of code (Ranges.jl, RecursiveArrayTools.jl, etc.) or in the low hundreds (RecipesBase.jl, Parameters.jl, SimpleTraits.jl). These are all tiny and Julia-only dependencies (so no build problems) which I don't think any informed individual should have a problem with (which in many cases people might not know about the common small dependencies like RecipesBase if they aren't involved in many packages), if they are accepting more than 0 dependencies. For something like ODEInterface, it is a 0 dependency library which is very nice because then it's still useful in isolation. The only good solution there is conditional dependencies.