Convert scalar data to 0-dimensional arrays

[sethaxen]

This PR fixes an issue raised by @goedman in StanJulia/StanSample.jl#60 (comment) wherein if one passes an observed_data such as (J=8, y=[1, 2, 3]) to from_namedtuple, one hits a StackOverflow since the method assumes all data in the NamedTuple are arrays.

This PR fixes this by wrapping all non-array data within a NamedTuple with fill to make a 0-dimensional array. It also ensures that these arrays are correctly (de)serialized with netCDF.

Currently tests fail due to rafaqz/DimensionalData.jl#421

[codecov-commenter]

Codecov Report

Merging #36 (54f78b9) into main (84a5aa8) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #36      +/-   ##
==========================================
+ Coverage   95.94%   96.00%   +0.05%     
==========================================
  Files           9        9              
  Lines         296      300       +4     
==========================================
+ Hits          284      288       +4     
  Misses         12       12              

Impacted Files	Coverage Δ
src/from_namedtuple.jl	95.12% <ø> (ø)
...ferenceObjectsNetCDF/src/InferenceObjectsNetCDF.jl	95.45% <100.00%> (+0.14%)	⬆️
src/dataset.jl	92.85% <100.00%> (ø)
src/utils.jl	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[sethaxen]

Currently keyword indexing (rafaqz/DimensionalData.jl#423) and the Tables interface (rafaqz/DimensionalData.jl#424) also fail for AbstractDimStacks that contain 0-dimensional arrays, so those would need to work before merging this.

Alternatively, we could take xarray's approach of promoting to a single-element vector and introducing a dummy dimension. There's no real downside to this, and since it just works ™️, perhaps we should adopt that approach instead.