[Feature Request] ELF loader support for physical/virtual KASLR

# Feature Request

Currently, the x86 kernel is loaded into a fixed physical address and runs at a fixed virtual address. Physical/Virtual KASLR is not available, as it is only handled for bzImage during decompression, missing out on an additional layer of defense against code reuse attacks. KASLR is easily broken by information leaks, but since Firecracker uses short-lived VMs, KASLR might be a desirable feature because the VMs will be frequently re-randomized.

## Describe the desired solution

- Physical KASLR
`kernel_offset` argument to `loader::elf::Elf::load()` effectively does physical KASLR by allowing the kernel to be loaded at an offset from the default at `CONFIG_PHYSICAL_START`. So we only need to provide a `kernel_offset` that is aligned to `CONFIG_PHYSICAL_ALIGNED`.
For PVH entry, the current code in linux_loader doesn't support physical KASLR. If we provide a kernel_offset, it will choose to use the Linux 64-bit boot protocol. However, in the Linux kernel, physical KASLR for PVH entry has been allowed since commit [47ffe0578aee45fed3a06d5dcff76cdebb303163](https://lore.kernel.org/lkml/20240823193630.2583107-6-jason.andryuk@amd.com/) which introduced a new PVH ELF note that imposes the relocation range. I can change the handling in `linux_loader` to adapt to this.

- Virtual KASLR
There is no available function in `linux_loader` for now. However, it is easily to implemented, all we need is the relocation information for kernel. In x86 kernel, there is a `vmlinux.relocs` file which contains all relocation information needed, so what we need is to read it and perform relocation like `handle_relocations()` in `arch/x86/boot/compressed/misc.c`. The only discussion is where to implement it: in `Firecracker` or `linux_loader`.

## Describe possible alternatives

As for virtual KASLR, I have another possible implementation approach: to do it directly in the kernel when booting from `vmlinux`, see this [patchset](https://lore.kernel.org/lkml/cover.1769434279.git.houwenlong.hwl@antgroup.com/), then it doesn't need any changes in VMM, however, I'm not sure if it would be acceptable by the x86 folks.

## Additional context

## Checks

- [*] Have you searched the Firecracker Issues database for similar requests?
- [*] Have you read all the existing relevant Firecracker documentation?
- [*] Have you read and understood Firecracker's core tenets?

Start with loader::elf::Elf::load() and the existing linux_loader PVH handling to understand how kernel_offset selects the boot protocol. Compare the x86 kernel relocation approach in arch/x86/boot/compressed/misc.c and the vmlinux.relocs data, then resolve whether relocation belongs in Firecracker or linux_loader. Done means physical and virtual KASLR work for the supported x86 boot paths without breaking PVH loading.

Written by the indexing model from the issue text.