Add new_vol_like convenience function

[clin045]

Added convenience function for creating new volumes, analogous to nilearn's image.new_img_like. This is perhaps too trivial to add as a function, but new_img_like is something that I reach for regularly when working with nilearn, and I think it would benefit NIfTI.jl as well.

[codecov[bot]]

Codecov Report

Merging #60 (3a58f45) into master (06d4ce3) will increase coverage by 0.08%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #60      +/-   ##
==========================================
+ Coverage   52.27%   52.36%   +0.08%     
==========================================
  Files           6        6              
  Lines         549      550       +1     
==========================================
+ Hits          287      288       +1     
  Misses        262      262              

Impacted Files	Coverage Δ
src/NIfTI.jl	73.14% <100.00%> (+0.25%)	:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

[Tokazama]

After a bit of a hiatus Im back and reviewing stuff here. I have to think about this one a bit more because NIVolume probably shouldn't be a thing. It requires that this package maintains an independent array type from others in the scientific community so someone doing heavy optimizations elsewhere might be missed here. I'm also not super excited to deal with problems from breaking changes though

[clin045]

What exactly do you mean by that? Forgive me if I'm being naive, but since this is simply a wrapper for arrays + some metadata, wouldn't array optimizations still carry over to NIVolumes? I imagine that most heavy processing steps would begin with dumping out the raw data from the NIVolume anyways -- thus the convenience of having a new_vol_like() function.

[Tokazama]

If you care for the long version take a look at this demonstration of poorly optimized wrapped arrays for a basic copy method. https://github.com/JuliaArrays/ArrayInterface.jl/issues/235#issuecomment-1006327577

You're right that 80% of the time it won't make a noticeable difference, especially compared to other languages, but I'm greedy and a bit lazy. I want all of my methods to be as fast as possible and I want to maintain as few array types as possible. More importantly, we want to use as many well maintained community packages so we can focus on the neuroscience.

There are some other issues with the current approach but I would rather we focus on getting you a workable solution. Are you just trying to create new instances so you can save to a nifti file