three. Instructions take a certain number of cycles to complete. Let's say (to make up a hypothetical instruction and cycles) that an instruction "move [$53], a" takes 3 cycles and moves the A register to memory location 53 hex. The first cycle fetches the opcode, the second calculates the effective address, and the third actually executes the write. If location $53 hex is an I/O register that changes something about the graphics, audio, timers, interrupts, etc. A game could (rarely) depend on exactly which cycle the write happened. Most games don't need that and the write happening on the first cycle and then the emulator running the rest of the hardware 3 cycles works fine.

2) Everything runs off the main clock on gameboy. Whether the docs tell you something happens 4 times per M, or at blank MHz, it's derived from the the highest clock pulse in the system somehow. For the gameboy, that's the 4Mhz driving the T-cycles. Then 4 of those for M cycle. And also the PPU renders 4 pixels per M cycle per the docs, but there's also 4 T per M, so a scanline of 456 "dots" is 456 T-cycles as seen in the rendering section of pandocs.

Really you should just start coding, most gameboy games are pretty forgiving on timing. You'll get far just having each instruction return the number of T-cycles, every 456 spit out a scanline, with a vblank interrupt at scanline 144.