The unsupported part should basically be signaled via making that
value inaccessible

Not calling recv when data is received will accumulate data in the
internal recveive buffer until it's full, in which case is will stop
acknowledging.  This can lead to unjustified disconnections.

Removes unnecessary allocations for the os_event_* and os_sem_*
thread functions

This works around a crash in the "widget->clear()" call in
ClearListItems under the following circumstances:
- Create at least two scenes
- Create at least one source in both scenes
- Have at least one source selected in both scenes
- Set the same "Switch to scene" hotkey on both scenes
- Use "Switch to scene" hotkey

Reduced stack trace on my machine:
    frame #0: 0x00000001004bac2d QtWidgets`QWidget::show() + 93
    frame #1: 0x00000001006d32a2 QtWidgets`QAbstractItemView::updateEditorGeometries() + 690
    frame #2: 0x00000001006d36d7 QtWidgets`QAbstractItemView::updateGeometries() + 23
    frame #3: 0x00000001006f1ae6 QtWidgets`QListView::updateGeometries() + 438
    frame #4: 0x00000001006ccdce QtWidgets`QAbstractItemView::doItemsLayout() + 46
    frame #5: 0x00000001006f1916 QtWidgets`QListView::doItemsLayout() + 214
    frame #6: 0x00000001006f9cf3 QtWidgets`QListViewPrivate::rectForIndex(QModelIndex const&) const + 611
    frame #7: 0x00000001006eb48d QtWidgets`QListView::visualRect(QModelIndex const&) const + 29
    frame #8: 0x00000001006f1567 QtWidgets`QListView::visualRegionForSelection(QItemSelection const&) const + 1863
    frame #9: 0x00000001006d7ba9 QtWidgets`QAbstractItemView::selectionChanged(QItemSelection const&, QItemSelection const&) + 73
    frame #10: 0x00000001006f97d2 QtWidgets`QListView::selectionChanged(QItemSelection const&, QItemSelection const&) + 674
    frame #11: 0x00000001006d9b9e QtWidgets`QAbstractItemView::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) + 1246
    frame #12: 0x0000000102b10372 QtCore`QMetaObject::activate(QObject*, int, int, void**) + 2994
    frame #13: 0x0000000102aa001c QtCore`QItemSelectionModel::emitSelectionChanged(QItemSelection const&, QItemSelection const&) + 300
    frame #14: 0x0000000102a9fe6c QtCore`QItemSelectionModel::select(QItemSelection const&, QFlags<QItemSelectionModel::SelectionFlag>) + 748
    frame #15: 0x0000000102aa048b QtCore`QItemSelectionModel::clear() + 75
    frame #16: 0x000000010072e9d8 QtWidgets`QListWidget::clear() + 24
    frame #17: 0x000000010015759d obs`ClearListItems(widget=0x000000010683afa0) + 141 at item-widget-helpers.cpp:43
    frame #18: 0x000000010003424b obs`OBSBasic::UpdateSources(this=0x0000000105f5bf50, scene=(val = obs_scene * = 0x0000000110679440)), &(obs_scene_release)>) + 75 at window-basic-main.cpp:1254
    frame #19: 0x0000000100036a96 obs`OBSBasic::UpdateSceneSelection(this=0x0000000105f5bf50, source=<unavailable>), &(obs_source_release)>) + 422 at window-basic-main.cpp:1473
    frame #20: 0x0000000100175c48 obs`OBSBasic::qt_static_metacall(_o=0x0000000105f5bf50, _c=InvokeMetaMethod, _id=17, _a=0x00007fff5fbfb640) + 776 at moc_window-basic-main.cpp:494

This crash was reported at
https://obsproject.com/mantis/view.php?id=364

SetThreadExecutionState with ES_DISPLAY_REQUIRED has the same effect of preventing the screensaver from activating. Using SPI_SETSCREENSAVEACTIVE leaves the screensaver disabled system-wide if OBS crashes before it can re-enable it.

The 'stopping' variable is superfluous due to the fact that 'stop_event'
accomplishes essentially the same exact thing.

If there was an attempt to destroy the rtmp-stream output while it was
already connecting and stopping at the same time, it would try to join
with the stop thread rather than with the connect thread.  The connect
thread would then continue past destruction.

The code assumed that the service was valid when that may not be the
case by the time it gets to the code.

Sometimes stopping a connection can lock up due to data that still
remains to be sent, and this would lock up the thread requesting the
stop (typically the UI thread).  So instead of locking up the calling
thread, spawn a new thread specifically for stopping so the calling
thread can continue uninterrupted.  If the user attempts to reconnect,
it will wait for the stop thread to complete in the connect thread
before attempting to connect.

If packets get backed up for too long of a time, just disconnect instead
of trying to output them all.

It's possible that packets would still be coming in while the packets
were being freed.

Currently creating new sources can cause a deadlock:
OBSBasicSourceSelect locks the scene mutex when adding a new source
(required to add invisible sources), and later OBSBasic tries to
lock the graphics mutex (via CreatePropertiesWindow); meanwhile the
graphics thread is holding the graphics mutex and tries to lock each
scene as it renders them, resulting in a (non-obvious from the code)
lock ordering conflict.

Moving the CreatePropertiesWindow call out of the locked scene mutex
restores the previous lock ordering; in addition, the requirement
for keeping sourceSceneRefs for opening that initial properties
window is removed

Adds JOICASTER as a service selection.

When an async video source is about to be rendered, the async texture
should be updated before any effect filtering occurs, rather than right
when it's about to render.

Fixes a few bugs:

- If the async texture hadn't drawn for its first time, and the source
  has an effect filter, it would never end up rendering the first
  frame due to the fact that it would fail on obs-source.c:2434 for the
  first filter, causing it to never actually render the source, and thus
  never get to a point in which it could call set_async_texture_size to
  establish the async texture width/height for the first time.

- Any time the async texture size changed, it would only update the
  async texture size at the end of the filter loop, which means that the
  first frame after a size change would use the old size for the filters
  rather than update to the new size right away.

A null pointer to a release/destroy function should be considered legal,
and simply do nothing.

Passing 0,0 texture size should be considered legal, and safely return
false to indicate that rendering can't begin.  Also there's no need to
try to use the current swap chain's width/height if either of the sizes
are 0, there's no need try try to "force" success here anymore.

Passing null pointer values to the destroy functions should be
considered legal and simply ignored.

Renames functions:
gs_shader_setmatrix3 -> gs_shader_set_matrix3
gs_voltexture_getdepth -> gs_voltexture_get_depth