Fix WAV export crash caused by uninitialized variables

[nyanpasu64]

This pull request aims to fix random crashes the first time you export a WAV file from FamiTracker.

bool CSoundGen::m_bStoppingRender failed to be initialized. If it happened to be nonzero, (audio) CSoundGen::OnIdle() would count down m_iDelayedEnd to 0 and then call StopRendering() on every frame, which would fail because IsRendering() is false. (This error was silent on release builds before #353, but now dumps a log and blocks the audio thread with a dialog.)

The crash happens when the user initiates a render on the GUI thread (setting m_pWaveFile and m_bRequestRenderStart). While the audio thread is looping, OnIdle() → StopRendering() could succeed and erase m_pWaveFile before (audio) CSoundGen::DispatchGuiMessage() processes WM_USER_START_RENDER from the GUI. Attempting to render without m_pWaveFile would crash.

Fix this by initializing CSoundGen::m_bStoppingRender, as well as other flags that the code doesn't access immediately but I don't want to leave uninitialized. I didn't initialize everything because I don't understand the existing code.

Crash log:

(audio)
(m_bStoppingRender) { CSoundGen::StopRendering
    ASSERT(m_bRendering) failed
} !IsRendering(), CSoundGen::StopRendering
repeats...

(m_bStoppingRender) { CSoundGen::StopRendering
    ASSERT(m_bRendering) failed
    ...

(gui)
{ CSoundGen::RenderToFile
    m_pWaveFile = std::make_unique<CWaveFile>();
    m_bRequestRenderStart = true;
    CSoundGen::GuiPostMessage(WM_USER_START_RENDER)
} CSoundGen::RenderToFile

(audio)
    m_pWaveFile.reset();
} CSoundGen::StopRendering
(WM_USER_START_RENDER:)
{ CSoundGen::OnStartRender
    {} Lock()
    m_bRendering = true;
} CSoundGen::OnStartRender
{ CSoundGen::FillBuffer
    if (m_bRendering) {
        ASSERT(m_pWaveFile) failed
        (crash)

This pull request improves upon and supercedes #272.

---

Also update the logging infrastructure to "Don't hold mutex during WAV export error dialog".

• Do we keep the WAV logging infrastructure indefinitely, or remove it once people stop hitting crashes in the wild?

Changes in this PR:

• Fix WAV export crash caused by uninitialized variables.
  • Fixes Program crashes frequently when exporting .wav files #190?
  • See wav export progress dialog does not appear on some projects #159.

[Gumball2415]

Do we keep the WAV logging infrastructure indefinitely, or remove it once people stop hitting crashes in the wild?

i think a crash logger in general would definitely help in pinpointing some blind spots regarding the concurrency and state issues of FT, so i'd keep it for now

[Gumball2415]

lgtm, will be merging soon