Unaligned bsp data causing a bus error on ARM

[Shivansps]

This is a 20-year old oversight, as this also happened on ModelView32, that on the readme it says that they were cutting what they belived it was useless data. And no one realised this since it just worked on x86.

The issue is that all bsp data, bsp colliders, etc, all chunks must be aligned so all offsets are divisible by 4, otherwise it would cause a crash when attempting to load the pof (and on a shield impact) on FS2 Open running on a ARM cpu, this case a Raspberry PI 3 and 4.

Original Volition model files are all aligned.

[Goober5000]

Thread for context: https://www.hard-light.net/forums/index.php?topic=96055.0

Here's the section of the readme:

- If you save a POF in the editor that you just extracted from the original
  FreeSpace 1/2 .VP files, the file will be a bit smaller than the original
  file, even though nothing changed. This is not a bug, there is no
  information lost. However the original Volition editors wasted some bytes
  containing nothing but null or CRLF bytes at the end of strings, which are
  however totally useless. MODELVIEW in contrast cuts strings to their actual
  content.

[Shivansps]

After looking into this issue myself i have the guidelines to properly align the data:

1) All chunks offsets no matter what must be divisible by 4. 2) All strings lenght must be divisible by 4, this means every chunk with a string the lenght must be adjusted so it is divisible and fill the extra characters with a null terminator 3) If a string is empty, for example "properties" on OBJ2 chunk the length must be 4, not 0, and the string must cointain 4 nulls terminators. 4) Defpoints is the only chunk on bsp_data that has a chance to be unaligned, it is important to ensure the defpoints chunk size is divisible by 4, and the vertex data offset inside is also divisible by 4. 5) Nothing can be done about the SLDC chunk, the system is unaligned by design, so only adjust the size if needed so the next chunk after it is aligned.