Because it’s for school, there are some softwares that don’t play nice with virtual machines (like proctoring softwares)
Makes sense. Then dual booting may be the best and it seems you already have the info needed.
It would be interesting if you were to both dual boot and still create a windows VM on the fedora host for testing purposes. Knowing what would or would not work and posting the results may help the developers improve the VM management software and tools.
I’ve had good luck with temporarily disabling Bitlocker before installing Fedora which modifies the boot process, as well as before updating GRUB, as well as triggering a reboot-into-firmware/safemode from Windows, rather than a restart, to ensure Windows isn’t serializing any state into the hibernation/pagefile that is needed to initialize hardware (my wifi card won’t be fully reset and won’t be in the right state for linux to manage otherwise).
IIUC Bitlocker disk encryption stores the key/passphrase in the TPM which analyzes and creates a hash of each block of code which runs during the boot process, if the boot process is unchanged it automatically unlocks the key to the Windows bootloader/early kernel so the disk can be unlocked and booted, but if anything changes in the code running the boot process, because something has been subverted, the drive has been moved to another machine, or in this case because GRUB is now in the middle of the boot process, you have to enter the disk encryption key on the console manually; so make sure you have a backup of the encryption key accessible offline so you can manually enter it if needed.
When you disable Bitlocker temporarily from the Control Panel, it stores the key somewhere not in the TPM temporarily (I think) and upon the next boot will re-measure teh boot process and re-seal the key into the TPM based on the new measurement of all the code which runs during early boot. This is often done automatically during firmware updates, eg if you update EFI or a GPU firmware that will change the measurement too and will need Bitlocker to re-measure the boot process.
This is separate from SecureBoot which uses a certificate store in the EFI firmware to check the signature of each block of code which runs in early boot to make sure it’s unmodified and signed, you can add your own cert to the store to sign your own firmware if you like but most systems are capable of booting Windows so most organizations just ask Microsoft to use their certificate to sign their firmware or bootloader, so the owner doesn’t have to fiddle with the firmware if they don’t want to. The checking is only as good as the certificate authoritizes that the firmware vendor bakes into the flash out of the box, “TEST CERT DO NOT USE” should probably be replaced with a real one manged by the hardware vendor 
Once the system loads the bootloader and is no longer in EFI I don’t think SecureBoot matters anymore, it’s up to the OS on what policy it has for loading kernel modules and whatnot, Linux can support signed modules but I don’t know how that enforcement is configured.