Replace stb_vorbis with libvorbis

[ellenhp]

Fixes a variety of crashing bugs in stb_vorbis, and I think it also fixes #26964 but I will have to do a bit more testing to confirm that.

This introduces a size penalty of approximately 5% over the old internal representation of ogg files, but I think getting rid of stb_vorbis is worth it.

Important: If this gets merged and we ever want to revert it or switch to a new library or something, it's critical that we keep the change I made to editor_file_system.cpp otherwise whatever .ogg importer we replace this one with won't be run, and the engine will just crash instead.

[aaronfranke]

You need to update the documentation for the CI checks to pass.

[reduz]

This is looking extremely good so far!

[ellenhp]

I switched the names around, moved OGGPacketSequence to its own file in the ogg module, switched to using cache-friendlier data structures for the ogg packet data, and generally cleaned things up a bit. What this PR really needs right now is testing, not necessarily an in-depth review. Happy to respond to comments but what I'm most concerned about right now is it not actually working with some ogg files due to something I missed in the spec. It works with anything created with ffmpeg from my experience.

I'll put this in the PR description too but storing the ogg bitstream as a list of packets in a variant array does result in a size penalty compared to storing it unprocessed. The penalty is fairly severe before compression (25%+), but seems to be about 2-4% after re-compressing the saved oggvorbisstr file in a zip. I assume that during exports there will be compression applied so I'm hopeful this isn't a big issue?

Additionally, this PR splits out the OGGPacketSequence from the vorbis code. I'd prefer to keep it this way and to expose the OGGPacketSequence code because that will make an opus plugin very easy to write and maintain.

edit: There are architectural issues with reusing the OGGPacketSequence code, so it might need to be duplicated in an opus plugin. Still, keeping it separate from the vorbis code makes logical sense to me.

[ellenhp]

I think (hope?) I've addressed all the CI issues. This should be ready to review now.

[Calinou]

I assume that during exports there will be compression applied so I'm hopeful this isn't a big issue

PCK files don't use compression to speed up random file access, but ZIP archives exported by Godot do. Nonetheless, the vast majority of users use PCK files.

[ellenhp]

Nonetheless, the vast majority of users use PCK files.

Good to know. Let's wait to merge this until I figure out how to reduce the size penalty. I think I have some ideas.

[ellenhp]

The size penalty for the new imported type (oggvorbisstr) now seems to be around 5% over the old imported type (oggstr), which is pretty good.

I'm discarding some information to accomplish this then reconstructing it:

• b_o_s (beginning of stream): I can reconstruct this perfectly because each OGGPacketSequence contains only one logical stream, so this is 1 for the first page, 0 otherwise.
• e_o_s (end of stream): Similarly to b_o_s, I'm reconstructing this by looking at the position in the stream of any given page.
• granule_pos: I store this unmodified. I need it for seeking so I can't discard it.
• packetno: I reconstruct this by starting at zero for the first packet popped out of the OGGPacketSequence, then incrementing it for each packet. I reset it to zero whenever a seek is performed. This works, but it's not compliant with the standard I'm sure. I went through the libvorbis source code and it's only ever used for detecting holes/missing packets in the stream as far as I can tell, so I think what I'm doing is fine. The value isn't important, all that matters is that it increments by 1 for each contiguous packet.

There's one additional caveat to this PR:

• The importer and stream code currently only support ogg vorbis files with a single logical stream, so "chained" streams will only partially import. All logical streams after the first will be discarded. I don't know how common these files are in practice, but I suspect they're very uncommon.

[reduz]

Looks really good! Please squash commits so I can review and eventually merge.

[reduz]

This looks amazing, awesome job!