The entire kernel is loaded into memory at boot, typically along with an initramfs nowadays. (It is still possible to set up a system to boot without an initramfs but that's unusual on desktops and servers.)
The initramfs's role is to provide the functionality needed to mount the "real" filesystems and continue booting the system. That involves kernel modules, and also various binaries: you need at least udev, perhaps some networking, and kmod which loads modules.
Modules can be loaded into the kernel later than just boot, so there's no special preparation of the kernel by the initramfs. They can be stored anywhere: the initramfs, /lib/modules on the real filesystem, in a development tree if you're developing a module... The initramfs only needs to contain the modules which are necessary to mount the root filesystem (which contains the rest).
Q1: “It” is wake_up. It wakes up all tasks that are waiting for the disk data. If they weren't waiting for that data, they wouldn't be waiting on that queue.
Q2: I'm not sure I understand the question. Each wake queue entry contains a pointer to the task. try_to_wake_up receives a pointer to the task that it's supposed to wake up. It is called once per function.
Q3: There are lots of wait queues. There's one for every event that can happen. The disk driver sets up a wait queue for each request to the disk. For example, when the filesystem driver wants the content of a certain disk block, it asks the disk driver for that block, and then the request starts with the task that made the filesystem request. Other entries may be added to the wait queue if another request for the same block comes in while this one is still outstanding.
When an interrupt happens, the disk driver determines which disk has data available from the information passed by the hardware and looks up the data structure that contains the kernel data for this disk to find which request was to be filled. In this data structure, among others, are the location where the data is to be written and the corresponding wake queue indicating what to do next.
Q4: The process makes a system call, let's say to read a file. This triggers some code in the filesystem driver which determines that the data needs to be loaded from the disk. That code makes a request to the disk driver and adds the calling process to the request's wait queue. (There are actually more layers than that, but you get the idea.) When the disk read completes, the wait queue event triggers, and the process is thus removed from the disk's wait queue. The code triggered by the wait queue event is a function supplied by the filesystem driver, which copies the data to the process's memory and causes the read system call to return.
Best Answer
The Unix boot process has (had) only limited capabilities of intelligently loading a program (relocating it, loading libraries etc). Therefore the initial program was an exact image, stored on disc, of what needed to be loaded into memory and "called" to get the kernel going.
Only much later things like (de-)compression were added and although more powerful bootloaders are now in place, the image name has stuck.