Update methods to specialize on mod argument

[omus]

While investigating invenia/Intervals.jl#144 I noticed this invalidation:

inserting -(a, b::Interval) in Intervals at /Users/omus/.julia/dev/Intervals/src/interval.jl:314 invalidated:
   mt_backedges: 1: signature Tuple{typeof(-), Module, Any} triggered MethodInstance for _in_range(::Module, ::AbstractRange{Module}) (1 children)
   49 mt_cache

An AbstractRange{Module} seemed strange so I did some digging and noticed m.method.module ∈ mod inside of methods. As far as I can tell nothing is actually creating a AbstractRange{Module} but, possibly due to @nospecialize, the compiler seems to be specializing in calls for all possible arguments. (Note: this is purely theory crafting on my part)

Restricting the argument to Array eliminates the invalidation. We could probably reduce the argument to Vector safely but that would require some changes to the docstring.

[DilumAluthge]

It seems reasonable to me to further restrict it to Vector{Module}, with an appropriate update to the docstring.

[rfourquet]

I don't think tricks to reduce invalidations should have such user-facing consequences. IMHO there is no good reason to limit to Vector here (but limiting to AbstractVector is fine). Wouldn't you get the same results if instead you convert mod::AbstractVector at the beginning of the function to a Vector, like mod = Vector(mod) ?

[timholy]

It's better to do that conversion in a "stub" method and then have the "real" method be picky about its inputs: https://docs.julialang.org/en/v1/manual/style-guide/#Handle-excess-argument-diversity-in-the-caller

"Infer & compile long methods only a few times, infer and compile short methods as many times as you want to."

[omus]

Another way to eliminate the invalidation is to remove the @nospecialize from the mod argument. After reviewing the original PR I think the @nospecialize was added to the mod parameter by default and not for any performance reasons.

Additionally, supporting passing in Nothing and Tuple{Module} as the mod parameter seems to just be for internal use and should probably refactored out of the public facing interface. I'll leave that for a separate PR