Query cubeb to calculate precise `shm_area_size` for a given stream configuration

[kinetiknz]

PR #121 provides a way to specify a per-server shm_area_size via a new parameter to audioipc_server_new_client, allowing Gecko to specify a suitable value. This removes the previous hard-coded guess of 2MB, which is too large for most streams but potentially too small for streams with a large number of channels or very high latency request.

This could be improved by extending cubeb's API to provide a way to query the required shm_area_size on a per-stream basis during configuration. Requires a new API for cubeb with changes for each supported backend, and a new guarantee that the data_callback requests will never exceed the reported buffer size (this can happen in some backends in response to latency changes in the audio server, for example).

[kinetiknz]

A partial fix landed in 03868a0. We now allocate the size of the shm based on the stream's parameters, allowing for ~1s of audio (rounded up to 64kB). That reduces the allocation for a typical stream from 2MB to ~384kB.

The WIP patch at mozilla/cubeb#671 extends the cubeb API to expose the per-stream maximum buffer request size. For a typical stream, this further reduces the allocation to ~5kB (with no rounding, actual size will be rounded up to the next page).