MP3Decoder: better handle indicating end of mp3 audio data to caller

The old formulation
 * wouldn't work if there were ID3 tags at the end
 * would choose whether to background-refill the inbuf
   based on a check before skipping to the next sync word, which
   could be incorrect.

I think it was aspect "B" that ended up triggering the erroneous EOF
problem fixed in the prior commit. This would depend on specific data
sizes and offsets occuring in the file such that a read would be
scheduled but then the buffer would be filled and left 100% full by
find_sync_word(). It's just lucky(?) that a particular person produced
such a file, and/or many files produced by Audacity have those
characteristics.

Author: jepler

shared-module/audiomp3/MP3Decoder.c

@@ -356,15 +356,19 @@ audioio_get_buffer_result_t audiomp3_mp3file_get_buffer(audiomp3_mp3file_obj_t *
         return GET_BUFFER_DONE;
     }
 
+    self->samples_decoded += *buffer_length / sizeof(int16_t);
+
+    mp3file_skip_id3v2(self);
+    int result = mp3file_find_sync_word(self) ? GET_BUFFER_MORE_DATA : GET_BUFFER_DONE;
+
     if (self->inbuf_offset >= 512) {
         background_callback_add(
             &self->inbuf_fill_cb,
             mp3file_update_inbuf_cb,
             self);
     }
 
-    self->samples_decoded += *buffer_length / sizeof(int16_t);
-    return mp3file_find_sync_word(self) ? GET_BUFFER_MORE_DATA : GET_BUFFER_DONE;
+    return result;
 }
 
 void audiomp3_mp3file_get_buffer_structure(audiomp3_mp3file_obj_t *self, bool single_channel_output,