Collect stream chunks before passing to vstack

[gfetterman]

Fix #73

While I wasn't able to definitively track down precisely which change in numpy 1.17 introduced this problem, I believe it is related to a breaking change in a test build that removed the ability of numpy.vstack() and friends to accept generators, which was then rolled back in favor of a deprecation warning beginning in 1.16. If these deprecations were flagged in release notes, I haven't been able to find them.

The deprecation warning still shows up under 1.17:

>>> numpy.vstack((t, t + 1, t + 2) for t in range(10, 50, 10))
__main__:1: FutureWarning: arrays to stack must be passed as a "sequence" type such as list or
tuple. Support for non-sequence iterables such as generators is deprecated as of NumPy 1.16
and will raise an error in the future.
array([[10, 11, 12],
       [20, 21, 22],
       [30, 31, 32],
       [40, 41, 42]])

But manually reproducing one of the failing tests still produces an error:

>>> s = bark.stream.Stream(numpy.arange(1, 31).reshape(10, 3), sr=10)
>>> s.call()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[path-to-bark]/bark/stream.py", line 96, in call
    return np.vstack(self)
  File "<__array_function__ internals>", line 6, in vstack
  File "[path-to-conda-env]/lib/python3.6/site-packages/numpy/core/shape_base.py", line 282, in vstack
    return _nx.concatenate(arrs, 0)
  File "<__array_function__ internals>", line 6, in concatenate
ValueError: need at least one array to concatenate

So this can't be the sole cause of the bark test failures. But rolling all of a stream's chunks into a tuple before passing them to numpy.vstack() does resolve the problem, so there must be an interaction between numpy's expectations and the Stream class's iteration behavior producing the errors.

I think this is as deep as I can go at the moment. The previously failing tests run, and manual tests of complex functionality (including bark-label-view) don't break. And collecting the chunks before handing them to numpy.vstack() does not appear to produce a performance penalty (they'd just be collected by vstack() anyway).

This change now means that the numpy version doesn't need to be specified in the requirements file, and also releases the restriction on the pandas version (as pandas 1.3 requires numpy>=1.17).

[gfetterman]

This change also advances the latest supported python version to 3.10 for both the core library functions and the command-line tools.