Added support for playing a node specifying a sample rate

[jfsantos]

This is the beginning of an implementation to fix #33. For now, I have just created a function that allows specifying a sample rate instead of having to instantiate a stream by hand (to be used with, e.g., array players that do not have any info on the sample rate). If there's nothing wrong with this approach, we could add a similar function specialized for FilePlayer nodes (in this case, we do not need a sample rate argument, as the information is included in the AudioFile type.

[ssfrr]

Sorry for the slow response on this. In about a week I'll have some more time to dig back into a few AudioIO issues.

The idea with play opening up a stream is that it only does it if the stream isn't yet opened, and other play calls (overlapping or otherwise) should re-use the same stream. For that reason it feels odd to specify the sample rate as part of the play method. Also, for file playback the samplerate is a property of the file, so we should be able to automatically figure it out rather than the user specifying.

One thing I have on the agenda (#37) is to support auto samplerate conversion, which is how I'd rather handle this case. @JayKickliter has been working on pure julia resampling code, so it might not be too hard to incorporate it.

[jfsantos]

Auto sample rate conversion would be really nice for files, but we still would have problems when trying to play arrays. That would force the user to make all arrays in the same sample rate as the first stream that was opened. I know that makes sense for an application playing audio or for a live coding scenario, but it is a bit of a hassle when you are doing experiments and listening to their output in the REPL or in IJulia. That's the situation where I would use play with the sample rate as an argument.

Maybe we could come up with a compromise and add a function that supports passing a sample rate, but does on-the-fly conversion instead of opening a new stream?

[ssfrr]

I agree, array playback definitely shouldn't be forced to be locked to the final stream rate. I think what should happen is that play(arr::AbstractArray, sr::Float) should wrap the array in an ArrayPlayer that's running at the given samplerate, and the render process should transparently handle samplerate conversion if the AudioNode samplerate doesn't match the AudioStream's.