Use call for string to numeric conversion

[simonbyrne]

Fixes issue #10594.

[tkelman]

should this list get Float32 and Float64 added to it?

[simonbyrne]

These should be handled by https://github.com/JuliaLang/julia/blob/sb/parsefloat/base/deprecated.jl#L312-L317

[garborg]

I don't want to rush any decisions, but this would be great to resolve one way or the other before packages like JuliaParser.jl and LibExpat.jl make decisions about whether to keep exporting a parse that doesn't extend Base.parse.

[JeffBezanson]

I guess this is ok. IIRC, our thinking used to be that for something as simple as a number, construction and conversion should be the same thing, and that parsing should be done explicitly since it is slow.

[stevengj]

Looks good to me. (A perfect example of where T(x) should be defined but not convert(T, x), because we never want this conversion to happen implicitly.)

[stevengj]

In this case, why do we need parse{T<:Number}(T, x)?

[JeffBezanson]

Yes, I think that's a bit of a problem. If we have both, it's not clear which one to call or define. If we use only constructors, then the interface to parsing is construction. However this doesn't make sense for all types. For example List("(1 2)") could construct a list of one string, but parse(List, "(1 2)") would construct a list of two integers.