Fix #429 -- add branch-free paths for simple cases like CuArray{Float32}

[mcabbott]

This tries to add some fast paths for the common case, of ordinary arrays of numbers. They look like this:

julia> ProjectTo(rand(3))  # storing .element is now always redundant, could be generated by getproperty?
ProjectTo{AbstractVector{Float64}}(element = ProjectTo{Float64}(), axes = (Base.OneTo(3),))

julia> ProjectTo([pi, pi]')  # only AbstractVector{T} changed, not structured
ProjectTo{Adjoint}(parent = ProjectTo{AbstractVector{Real}}(element = ProjectTo{Real}(), axes = (Base.OneTo(2),)),)

julia> ProjectTo([[1,2], [3,4]])  # only for arrays of numbers
ProjectTo{AbstractArray}(elements = ProjectTo{...

Might close #429 .

Might also introduce weird dispatch ambiguities. I thought I hit places where I misunderstood how things like (p::ProjectTo{<:T})(dx::S) would be treated.

[mcabbott]

Here S and p.element are the same information: for every S<:Number, the projector can be reconstructed as ProjectTo(zero(S)). So perhaps tidier not to store it.

We can alter getproperty to do this. In which case, perhaps the projector for an array of arrays (which has an array p.elements instead) should also define it, via mapreduce(project_type, promote_type, projectors), even if that ends up trivial?

If you can always call p.elements, then you can insert that into some in-place rules, dx -> dx .+= ρ.(dy .* conj.(stuff...)).

[mcabbott]

This is slightly weird, but my idea for avoiding the if axes(dx) == projector.axes branch is to include the N only when the axes are Base.OneTo. If ndims(dx) matches, and its eltype matches, then it can pass through just by dispatch.

This means it won't check for quite as many size mismatches. But it will still reshape for OffsetArrays, SArrays, etc, those will go the "slow path" as before.