Use more optimised XSAVE for x86 kernel

[dreamliner787-9]

In similar spirit to #503.

Currently the Microkit build seL4 with just the base XSAVE instruction for context switching in the kernel. We should use the more optimised XSAVEC, XSAVEOPT, or XSAVES variants for better context switching performance.

The wrinkle with this is that it will raise the baseline CPU requirements of the Microkit and thus will be a breaking change. I don't think this will be a big problem for hardware deployments as I tested XSAVEOPT on the older x86 machines we have (Skylake and Haswell) and they supported it. But for VM deployments it might be an issue.

From the kernel's config.cmake on the differences between the variants:

config_choice(
  KernelXSave
  KERNEL_XSAVE
  "The XSAVE area supports multiple instructions to save
        and restore to it. These instructions are dependent upon specific CPU support. See Chapter 13 of Volume \
        1 of the Intel Architectures SOftware Developers Manual for discussion on the init and modified \
        optimizations. \
        XSAVE -> Original XSAVE instruction. This is the only XSAVE instruction that is guaranteed to exist if \
            XSAVE is present \
        XSAVEC -> Save state with compaction. This compaction has to do with minimizing the total size of \
            XSAVE buffer, if using non contiguous features, XSAVEC will attempt to use the init optimization \
            when saving \
        XSAVEOPT -> Save state taking advantage of both the init optimization and modified optimization \
        XSAVES -> Save state taking advantage of all optimizations. This instruction is only \
            available in OS code, and is the preferred save method if it exists."
  "XSAVE;KernelXSaveXSave;XSAVE_XSAVE;KernelFPUXSave"
  "XSAVES;KernelXSaveXSaveS;XSAVE_XSAVES;KernelFPUXSave"
  "XSAVEOPT;KernelXSaveXSaveOpt;XSAVE_XSAVEOPT;KernelFPUXSave"
  "XSAVEC;KernelXSaveXSaveC;XSAVE_XSAVEC;KernelFPUXSave")

[Indanz]

Please do careful benchmarking to make sure it actually improves anything.

If changing it, I would go for XSAVES, that should give the biggest speedup on newer CPUs. It is the recommended instruction to use if available.

This is another thing we could easily detect dynamically at runtime instead of being a compile option. But if unlucky, the extra branch will undo any gains. That said, on x86 the branch history should be big enough to avoid this in most cases, except when running virtual machines or other bloatware. The branch could be avoided if we do binary patching and replace XSAVE with XSAVES when available at early bootup, but that has other problems.