Read per-texture properties from a new TXPR chunk in POF files

[dustinspace217]

What?

POF models can now carry a properties string for each texture, read from a new TXPR chunk. Nothing uses the strings yet; they're the groundwork for per-texture settings like glow brightness.

Depends on #7863 (its commit is the first one here), so this stays a draft until that merges.

Why?

Goober5000 asked for settings that belong to a texture wherever its model is used: ships, weapons, skyboxes, shockwaves. The first use is glow brightness for a 3D shockwave in The Scroll of Atankharzim. Submodel $props don't fit, since they belong to one submodel and stop at 256 characters, and later settings like curves will need far more.

How?

• TXPR holds a count, then one length-prefixed string per TXTR entry, in the same order; an empty string means none. Older builds skip it like any unknown chunk, so there's no POF version bump.
• The strings go on polymodel::texture_properties, one per texture. They're read with the SCP_string cfread_string_len from Make cfread_string_len read no more than fits in the buffer #7863, so there's no 256-character limit, and reading stops at the end of the chunk.
• A string that runs past the end of the chunk is dropped with a warning, and so is a count that doesn't match the texture count.
• Virtual POFs that add a submodel bring along the properties of the textures they add.
• POF-Tools writes and edits the chunk: Add per-texture properties (TXPR chunk) Baezon/pof-tools#192. Older POF-Tools versions and PCS2 drop it when they re-save a model.

Testing?

test/src/model/test_texture_properties.cpp loads small POFs made with the POF-Tools branch. It checks:

• three textures, including an empty entry and a 6,000-character string;
• no chunk at all;
• a count too low, a count too high, and a string running past the chunk (byte-patched copies, Release only, because in Debug a warning thrown mid-load leaves parsing paused for later tests);
• a virtual POF that grafts a submodel.

I also broke each new check on purpose to confirm a test fails. Release and Debug unit tests pass with no warnings, and clang-tidy (CI's check) is clean.

In game, a Scroll model re-saved with properties loads with the same geometry as the original, on this branch and on master.

Anything Else?

I used Claude Code to write the change and tests and to run the checks; I reviewed the code and this text.

[The-E]

Why is this not a tbl setting?

What I am seeing here is a feature that relies on a change in the model file and a change in FSO, all stringly typed and with no actual feature tied to it - the FSO PR reads this new chunk, I see the test looking for some "$curve" property, but there's nothing done with it.
IMHO, the proper place for settings like this is the relevant table, not the model: TBL files have the immense advantage of not requiring specialized tools to edit, and are thus easier to access, understand and ultimately use than model file properties.

[BMagnu]

The point is that this is meant as the place to store the data for per-texture data (the glow map boost level), intrinsic to the model.
There is no good table for that data.
It shouldn't go into the ships table or something, because it needs to work for all uses of POFs. Ships, weapons, skyboxes, cockpit models, etc. And it should work the same for everything, without a modder needing to keep all these tables constant.
The only other sensible table would be a new, per-texture sidecar table, which is IMO strictly inferior to adding more POF properties, keeping the data sensibly in the mode.

As for nothing being used it for: This is a very different place of the engine, and keeping the POF change isolated is a lot cleaner.

[dustinspace217]

Closing this: following the Discord discussion, per-texture properties will live in a .mat text file next to the texture instead of in the POF. #7865 now reads them from there.