Linux – the current kernel build options stored

It's pretty straight forward, although we should distinguish between "driver" and "module". A driver may or may not be a module. If it is not, then it is built into the kernel loaded by the bootloader.

If it is a module, then it is in a filesystem hierarchy rooted at /lib/modules/[kernel-release].¹ Note that it is possible to boot a kernel together with a small preliminary root filesystem (an "initramfs") which may contain such a repository as well. This is normal with generic kernels so they can decide what modular drivers they need to load in order to access the real filesystem, since if they can't do that, they can't access any modules there.

Are drivers loaded by the kernel ?

Yes.

if so why are they already a part of the rootfs ?

Where else should they be stored before they are loaded? The kernel doesn't contain the rootfs within itself (except WRT some forms of initramfs), it's just the gatekeeper.

does the kernel overwrite them with the ones compiled in it ?

No. If you compile a driver in, the kernel will not bother to check /lib/modules for it. I'm not sure what happens if you then ask it explicitly to load such a driver anyway, presumably it will just say no.

^{1. As Celada hints at with $(uname -r), this release string is not necessarily just the version number. You can have multiple kernels with the same version and different release strings therefore separate module stores. Likewise, you can have multiple kernels with the same release string, therefore the same module store.}

One, arguably silly, idea that comes to mind is to see if you can pull the kernel's symbol table from the image or from /proc/kallsyms or somewhere, and reverse engineer at least the included drivers based on that. Though with something like 35000 symbols shown by kallsyms on a stock distribution kernel, that would require some scripting.