Rare crash on tempo automation when stacking and/or arpeggio is on

[PhysSong]

Reported by @FairPlay137-TTS#8972 on Discord. An example project that I made:
4536.zip

Here's the backtrace I've got:

(gdb) bt
#0  __memset_avx2_unaligned_erms ()
    at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:186
#1  0x000000000050e791 in NotePlayHandle::play(float (*) [2]) ()

It seems like NotePlayHandle::play calls memset when _working_buffer is nullptr.

lmms/src/core/NotePlayHandle.cpp

Lines 244 to 247 in 2ecc8bb

	if( m_totalFramesPlayed == 0 && ! ( m_instrumentTrack->instrument()->flags() & Instrument::IsSingleStreamed ) )
	{
	memset( _working_buffer, 0, sizeof( sampleFrame ) * offset() );
	}

The reason for the crash

• Stacking and/or arpeggio makes m_usesBuffer of the master note false.
• NotePlayHandle::resize changes m_totalFramesPlayed on tempo change. SA Envelope + (Rapidly) varying tempo give undesirable output. #3775.
• In some cases, m_totalFramesPlayed becomes 0 even though the note is being played.
• Thus, there can be master notes with m_totalFramesPlayed == 0.
• For those notes, NotePlayHandle::play calls memset with nullptr.

Possible solutions

• Drop the memset call. It should work fine thanks to 6fc4577.
• Fixing Envelope + (Rapidly) varying tempo give undesirable output. #3775 may also fix this, see e.g. Envelope + (Rapidly) varying tempo give undesirable output. #3775 (comment).
• Don't use m_totalFramesPlayed to check if the note was played before.

[PhysSong]

A little bit off-topic... Non-MIDI-based instruments check for m_totalFramesPlayed and create plugin data if the value equals 0. However, this issue shows that the method is unreliable. It means LMMS does unneeded allocations and removes the way to access previously allocated data.
I think we can replace the check with m_pluginData check instead.

[PhysSong]

Drop the memset call

Should I implement this?