Previously, processing a node would involve a temporary buffer
allocated on the stack. Because this was fixed size, it would result in
processing being sub-divided into chunks in order to avoid overflowing
that buffer. This becomes an issue when a node needs to have a known
processing size. An example might be some kind of effect that requires
processing be in powers of two.

With this commit, the `processingSizeInFrames` variable in
`ma_node_graph_config` can be used to make it so processing always
happens in fixed sized chunks. In this situations, it's recommended you
always call `ma_node_graph_read_pcm_frames()` with a frame count of a
multiple of `processingSizeInFrames`.

The allocation strategy used here is not optimal and will be improved
in future commits. It currently allocates a buffer per-node, but since
the data contained within it is transient in nature, it should be
possible to use a global fixed sized stack that supports allocating a
variable amount of space within the stack buffer.

Public issue https://github.com/mackron/miniaudio/issues/810

Public issue https://github.com/mackron/miniaudio/issues/805

Public issue https://github.com/mackron/miniaudio/discussions/800

Public issue https://github.com/mackron/miniaudio/issues/779

Use the MA_PTHREAD_REALTTIME_THREAD_PRIORITY define.

This is useful because MA_ASSERT is only defined in the implementation
section of miniaudio.h which can cause issues when people copy/paste
the code and use it in a file that does not have visibility of the
implementation.

Note that there are still more references to implementation-defined
macros, but these have been moved to the public section in the dev-0.12
branch so I'm not bothering to change those just yet.

Public issue https://github.com/mackron/miniaudio/issues/787

Use `#define MA_AAUDIO_MIN_ANDROID_SDK_VERSION 26` if you need to
support SDK version 26.

Define MA_AAUDIO_MIN_ANDROID_SDK_VERSION to specify the minimum
required SDK version for enabling the AAudio backend.

Public issue https://github.com/mackron/miniaudio/issues/781

Audio Worklets do not work with --closure=1 because the callback used
with emscripten_create_wasm_audio_worklet_processor_async never gets
fired which means miniaudio will never be able to escape from it's busy
wait loop.

Public issue https://github.com/mackron/miniaudio/issues/778

Public issue https://github.com/mackron/miniaudio/issues/779

Unlocked notification fires on emscripten upon successful resume of
audio context attached to a device.  This occurs only once per device
and it happens after the browser has received the input event
necessary to begin playing audio on most webpages.  This is due
to autoplay rules.

It is recommended to wait until this event is fired to start a
'main game loop' on the web.

Public issue https://github.com/mackron/miniaudio/issues/773

Public issue https://github.com/mackron/miniaudio/issues/770

This also fixes a possible crash during initialization due to leaving a
thread running after early termination of the initialization routine.