Enable stacking of 0-dim arguments #3

[manuelbb-upb]

I needed stacking to work with 0-dim objects.
This seems closely related to issue #3.
For me, however, the arguments to StackView really are array-like.
Julia's builtin stack can handle 0-dim objects.
With these small changes, the following code should work, too:

using StackViews

# 0-dim arrays
x = Array{Float64}(undef)
y = Array{Float64}(undef)

z = StackView(x, y)
z isa AbstractVector{Float64}   # true
z[1] = 1
z[2] = 2
z == [1, 2] # true

# 0-dim views
A = rand(2)
a1 = view(A, 1)
a2 = view(A, 2)
ndims(a1) == ndims(a2) == 0 # true
B = StackView(a1, a2)
B isa AbstractVector{Float64}   # true
B[1] = 1
B[2] = 2
B == A      # true, setting values in `B` affects views of `A`
B == [1, 2] # true

# Numbers 
# Numbers work (if given as `slices::Tuple`)
v = StackView((1, 2))
v isa AbstractVector{Int} # true
# setting values does not work! numbers are immutable!
# `Ref` does not work neither, issues with OffsetArrays

[johnnychen94]

I think I use typeof(first(frame_axes)) rather than eltype(prev) for a "performance" reason.
Mostly Any[...] vs [...]`, can you check if they still work similarly in terms of performance for non-trivial large arrays (ttfx time and average time)?

[manuelbb-upb]

I can do some comparisons today. Used eltype(prev) here because _apend_tuple assumes a homogeneous tuple prev anyways, and I thought eltype would be something like eltype(::NTuple{N, T}) where {N, T}=T. Upon closer inspection, eltype on tuple (or rather tuple types) is a bit more complicated, but there does not seem to be obvious problems with type stability.
With previous typeof(first(frame_axes)) there were issues because frame_axes == () for 0-dim slices. Alternative: new helper _fill_range_type with methods for non-empty tuples (falling back to typeof(first(frame_axes)) and for empty tuples (returning Base.Bottom e.g. )

[johnnychen94]

I just updated and enabled the CI on the master branch. Might be worth rebase on that so we have CI to test against this PR.