missing padding in PlayerCharacter.h date for VR users causing crashes when accessing

We were noting issues when our application was trying to access player quest data by VR users.

It seems #152 corrected an oversized unk6F0 array. But there still appears to be a 16-byte undeclared gap between unk6DC and unk6F0.

can pad be added to this data stuct so that it is proper aligned?

There may also be a gap between unk8B0's end (0x9C0) and questTargetsLock.

our current workaround:

    if (REL::Module::IsVR()) {
        auto& vrQuestLog = REL::RelocateMember<RE::BSSimpleList<RE::TESQuestStageItem*>>(player, 0, 0xB60);
        for (auto* stageItem : vrQuestLog) {
            scanStageItem(stageItem);
        }
        if (!result.inQuestLog) {
            auto& vrQuestTargetsLock = REL::RelocateMember<RE::BSSpinLock>(player, 0, 0x9C8);
            RE::BSSpinLockGuard lock(vrQuestTargetsLock);
            auto& vrQuestTargets =
                REL::RelocateMember<RE::BSTHashMap<RE::TESQuest*, RE::BSTArray<RE::TESQuestTarget*>*>>(player, 0, 0xB88);
            for (auto& [tQuest, targets] : vrQuestTargets) {
                if (tQuest && tQuest->GetFormID() == formID) { result.inQuestLog = true; break; }
            }
        }
        return result;

The gap appears to have been mention in the #152 PR:

https://github.com/alandtse/CommonLibVR/pull/152#pullrequestreview-4354053042

Clarify implicit padding gaps in VR_PLAYER_RUNTIME_DATA layout

include/RE/P/PlayerCharacter.h: unk6DC (/6DC/) to unk6F0 (/6F0/) leaves a 0x10 byte hole with no explicit padding member; unk8B0[0x22] (/8B0/) to questTargetsLock (/9C8/) leaves a 0x8 byte hole. This codebase already uses explicit pad... / _pad... members elsewhere in RE headers, so add explicit padding (e.g., pad6E0[0x10], pad9C0[0x8]) to document alignment and prevent future confusion.