Create space for 4 bytes copied from ROM filesystem

[queueRAM]

UVBlockCounts is the first filesystem block that includes counts for all the block types that follow. This is memset to 0 beforehand with size of 0x24, but when DMA from ROM, the block size is defined to be 0x28. This happens to work out since there happens to be 4 bytes padding between this 0x24 and the next struct in memory.

Create a new wrapper struct which explicitly allocates this 4 bytes to keep the code portable.

[queueRAM]

I looked through every file system struct type and concluded that the generator for the filesystem aligned the block sizes to 8 bytes, but the data itself was not aligned to 8-bytes. A good example of this are 3x PHTS in task data for HG. They begin on 4-byte boundary 0x33C044, should be 3 * 0x14 bytes = 0x3C bytes is then padded by 0x4 bytes to length of 0x40 so its and next blocks offsets stays aligned to only 4-bytes.

For the task data, this doesn't matter since the code copying doesn't use the filesystem's length parameter (here would be 0x40), but instead uses hard-coded expected sizeof() sizes (above example it will copy 0x14 * countPHTS = 0x3C).

Unlike the tasks, the UV block code blindly trusts the filesystem reported size and copies this to the structure in code. There is no signal that the offsets or data needs to aligned in the filesystem, but there are examples that all the lengths must align to 8-bytes so this is likely the case here as well. I view this as a bug not confirming the size, but it works out since there is enough space for it. I would be ok closing this PR.