Add eltype methods for Nullable

[johnmyleswhite]

This PR adds eltype methods for Nullable, some stdlib documentation for the non-container methods implemented by Nullable and fixes some small whitespace quirks in the stdlib docs.

[ivarne]

[off-topic]
Should we document that eltype works for (some, not all) types as well?

It seems to me like it would be better to only define eltype for types and have a two generic fallbacks, to make it work for values too.

eltype(x::DataType) = Any
eltype(x) = eltype(typeof(x))
#edited to add:
# Types who wants eltype to work will then define only one method for the type
eltype{T}(::Type{Nullable{T}}) = T
eltype{T,n}(::Type{AbstractArray{T,n}}) = T
eltype{T<:AbstractArray}(::Type{T}) = eltype(super(T))

[JeffBezanson]

Why would that be better? Working on values is more flexible; otherwise you're forced to represent something's element type in its type.

[JeffBezanson]

Ah, I see I might have misunderstood you: it would be better to have fallbacks that allow you to define eltype only for a type, rather than needing two definitions. Yes that would be good.

[johnmyleswhite]

Are there cases where something's eltype isn't perfectly determined by its type?

[JeffBezanson]

Right now I don't think there are any.

[ivarne]

I don't think so, but there might be possible to construct some examples where it is useful. Even with my suggestion you can still add eltype definitions to values, so it won't break anything.

[JeffBezanson]

I found a case where eltype is difficult to compute from the type (and in fact our current code is not fully correct). For Combinations and Permutations the best definition would be

eltype(p::Permutations) = typeof(p.a[[1:length(p.a)]])

[johnmyleswhite]

Ok. Should I wait and rebase this PR and after we switch to the fallovers?

[JeffBezanson]

I'll just merge this now, since it will be very easy to fix when we decide what to do with eltype.

[johnmyleswhite]

Thanks, Jeff.

[StefanKarpinski]

Regarding the permutation type, I've thought that we should maybe have a Permutation type that wraps something indexable and presents a permuted view of it. That would eliminate the copying performance issue that this has and if that types is immutable, would force explicit copying to be done if the user wants to do mutation.