Restrict zero function types

[cjprybol]

Base only provides zero(::Type{T}) where T<:Number, not zero(::Type{T}) where T, and our method results in StackOverflows when called with Any when it should return an error. See JuliaData/DataFrames.jl#1251

[codecov-io]

Codecov Report

Merging #44 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master      #44   +/-   ##
=======================================
  Coverage   92.13%   92.13%           
=======================================
  Files           1        1           
  Lines          89       89           
=======================================
  Hits           82       82           
  Misses          7        7

Impacted Files	Coverage Δ
src/Nulls.jl	92.13% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f54c091...4111551. Read the comment docs.

[nalimilan]

@quinnj Please don't merge PRs during the night! Unless it's blocking something, I think a PR should sit for at least one day in case somebody has remarks.

We had already spotted the problem before introducing zero (https://github.com/JuliaData/Nulls.jl/pull/31/files#r141323811), but merged it anyway because zero doesn't not only work on Number. At the very least, it should also work for date types. Then it's debatable whether it's OK to add more methods for each type which might support zero, or whether we really need a generic fallback despite the StackOverflow error it triggers.

[quinnj]

Sorry, I thought it had been open longer. I feel like we should be more conservative here. We can add a method for Union TimeTypes and more as needed, but I feel like it's too easy to bump into zero calls out in the wild to be triggering stack overflows.

[nalimilan]

We should have a policy for this kind of situation. For example, we currently define * only for Number, so it doesn't work for strings. If we decide to overload functions on a case by case basis, we should add AbstractString methods. The other approach is to accept Any arguments.

[nalimilan]

See #45.