rework result_type

[johnnychen94]

The essence of result_type is based on the eltype(a), and result_type(::PreMetric, ::AbstractArray, ::AbstractArray) only serves as an convenient method.

There are no functionality changes in this commit, only to reorganize the codes to ease future development.

---

For example, in ImageDistances.jl, we can easily extend result_type to Colorant types if we dispatch on Type:

for (ATa, ATb) in ((AbstractGray, AbstractGray),
                   (AbstractGray, Number      ),
                   (Number      , AbstractGray),
                   (PromoteType , PromoteType )) # Union{FixedPoint, Bool}
    @eval function result_type(dist::PreMetric, a::Type{Ta}, b::Type{Tb}) where {Ta<:$ATa, Tb<:$ATb}
        T1 = eltype(floattype(Ta)) # Gray{N0f8} -> Float32
        T2 = eltype(floattype(Tb))
        result_type(dist, T1, T2)
    end
end

In the meantime, dispatching on AbstractArray would introduces a lot of method ambiguities.

[nalimilan]

Sure, why not. Couldn't we even find a generic definition using oneunit and float?

[nalimilan]

This doesn't look relevant here.

[nalimilan]

I mean that this is a docstring for an internal function, so it doesn't seem necessary to explain what can be the use of that function. Anyway, if you prefer showing an example calling pairwise, please turn it into a runnable doctest.

[johnnychen94]

I simply delete this part in the new commit; the only reason I added this seeming-too-obvious example is because result_type is exported.

[nalimilan]

I hadn't realized it was exported. Anyway, looks good that way.

[johnnychen94]

Couldn't we even find a generic definition using oneunit and float?

I tried, but then I realized it's better not to change the behavior of those algorithms in the first PR. You're suggesting some breaking changes though.