fix Base.eltype methods and functions that take Type parameters

[baumgold]

No description provided.

[quinnj]

Was the original issue that we were defining eltype on the instances instead of types? That makes sense to me and I agree we should fix. But all the changes like:

isstringtype(::Type{T}) where {stringtype, T<:ListKind{stringtype}} = stringtype

should be reverted, as they're just over-complicating the methods and are functionally equivalent. i.e. in this particular example, ListKind is already concrete, so T <: ListKind doesn't really match any additional types, so we're just introducing an unnecessary type parameter in T.

[baumgold]

I reverted the changes you suggested as I can't seem to remember why I suggested them in the first place.

[codecov-commenter]

Codecov Report

Merging #404 (9127920) into main (6fe4ec0) will decrease coverage by 0.02%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #404      +/-   ##
==========================================
- Coverage   87.48%   87.46%   -0.02%     
==========================================
  Files          26       26              
  Lines        3244     3263      +19     
==========================================
+ Hits         2838     2854      +16     
- Misses        406      409       +3     

Impacted Files	Coverage Δ
src/ArrowTypes/src/ArrowTypes.jl	86.20% <100.00%> (ø)
src/arraytypes/compressed.jl	100.00% <100.00%> (ø)
src/eltypes.jl	86.05% <100.00%> (ø)

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more