Type stability

Counting the float operations, we currently aren't as type-stable as I was expecting

julia> using GenericFFT, GFlops
julia> rfft_plan = plan_rfft(zeros(Float16,1024))
GenericFFT.DummyrFFTPlan{ComplexF16, false, UnitRange{Int64}}(1024, 1:1, #undef)

julia> @count_ops rfft_plan*randn(Float16,1024)
Flop Counter: 61382 flop
┌────────┬─────────┬─────────┬─────────┐
│        │ Float16 │ Float32 │ Float64 │
├────────┼─────────┼─────────┼─────────┤
│    fma │       0 │       0 │       4 │
│ muladd │       0 │       0 │     153 │
│    add │   18449 │       0 │      83 │
│    sub │   16447 │       0 │      39 │
│    mul │   24622 │       0 │    1250 │
│    div │      40 │      23 │       2 │
│    abs │      40 │      19 │      17 │
│    neg │      15 │       0 │       3 │
│   sqrt │       0 │      19 │       0 │
└────────┴─────────┴─────────┴─────────┘

The Float32 operations might be miscounted similar to https://github.com/triscale-innov/GFlops.jl/issues/40 but I doubt the Float64 operations are. Just raising this as we may want to ensure type stability and explicit conversions rather than relying on promotions (which can easily cascade into Float64s where we don't actually want to use them). The output may still be of eltype T but users of this package probably want a Fourier transform fully in T when they provide an input vector of eltype T?

Reproduce the issue with plan_rfft(zeros(Float16,1024)), randn(Float16,1024), and @count_ops on the resulting multiplication. Trace the plan_rfft and execution paths to identify unwanted Float32 or Float64 promotions; done means a transform given element type T performs its operations in T where intended while preserving the output eltype.