- Opcode map (note that the GB CPU is not a stock Z80, it has different timings, different registers, different flags and different opcodes, do not use stock Z80 docs as a reference lest you end up with broken CPU emulation): http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html
- The GameBoy programming manual: http://www.romhacking.net/documents/544/
- Accuracy test ROMs, very useful to make sure your timings are ok and you emulate various quirks of the hardware: http://tasvideos.org/EmulatorResources/GBAccuracyTests.html
Also note that even if you focus on making an original (DMG) GameBoy emulator you should be able to add GameBoy Color support later without too much difficulty, it's a fairly straightforward evolution of the original hardware.
In the case of emulators I suspect that many developers nowadays never went underneath the syscall layer (or even beyond the interpreter) so if they're interested to learn about how it all works deep down it can be a good challenge. Of course the GameBoy is archaic in most ways but it's a start.
It's more like building a car in the garage. There's no real need to do, but some people enjoy the process of figuring out how everything fits together.
Emulators of other platforms tend to need tons and tons of work to even get to booting.
Kirby's Dreamland was programmed with a track ball running on a hacked up Famicom.  We haven't come too far since then.
We used the RGBDS assembler and its built in tools to make the thing, mostly because that runs on Linux and that's what we both wanted to develop on. My partner did the graphics and I got a decent flow going from LibreSprite using RGBGFX for the conversions.
I'll admit that I did have a major advantage going in, having written a mostly functional gameboy emulator already, but emulating a system is very, very different from programming against its constraints. There are decent software libraries floating around, but since there's no real standard way to leverage the hardware once you get past the basics (even commercial games had wildly varying strategies from company to company) the best tool in the belt is probably your documentation. Pan docs and the various wikis were instrumental in understanding how to leverage the hardware to do what we wanted.
Really excited about it. Good luck!
Used Acorn for a while now use Paintbrush.
But they are all still too complex and don’t get the feel right.
Paint in WINE!
But I agree, tooling is complicated. I'm currently adding the finishing touches to the rewrite of my own Assembler / Compiler pipeline  and started work on a more "traditional" Metroid-like shooter, the sprite and map editor are both custom programs written in rust using imgui bindings and take care of the grunt work for generating all the data structures used in the game currently the dev efforts are 50/50 tooling/game though :D
But in general I agree that the biggest problem with making retro games is getting a comfortable dev environment that just works. I think this is the motivation behind some of the 'simple' NES development environments that have been coming out.
I feel like a really good IDE / debugger and well documented library for the Gameboy + samples would go a long way.
Have you tried the SDCC C compiler? I use it for 8bitworkshop. It has a Gameboy CPU target.
I've written a couple of toy Gameboy emulators at this point. It's a bit challenging to get anything working, and honestly I have no idea how to approach audio at all. Nevertheless, it's still quite fun. The LCD timings are a point of curiosity for me. It seems there's still a slight bit of mystery around it, still today.
I was inspired to play with emulating Gameboy specifically after an excellent 33c3 talk, The Ultimate Game Boy Talk, which I highly recommend.
(Some day I would like to approach emulation for more platforms, both newer and older, but I feel I still have so much time learn about designing emulators that I haven't bothered with that yet. It's so open ended, and handling things like cycle counting has a lot of different approaches of varying desirability.)
Making an emulator run fast generally involves finding an efficient software architecture to emulate a piece of hardware (a non-trivial task since hardware is massively parallel and synchronous) and if you still can't get it to run fast enough you start cutting corners on accuracy until you do.
It was a lot of fun!
Can you recommend any starting paths for someone like you mentioned?
Step one is to understand the architecture of the system. What are the different hardware components? How do they interact?
A simple emulator boils down to:
For each cycle you have to produce any side effects from the various peripherals (serial comms, update the display, generate audio, etc.), process any external changes (button presses, serial data), and emulate the next CPU instruction (basically a big switch).
I recommend "The Ultimate Gameboy Talk (33c3)" , for an overview of the Gameboy and it's internal peripherals.
There are various test ROMs available that you can use to verify the basic functionality. 
Or you could just read the documentation directly here:
CHIP8 was itself an interpreted bit of hardware, so it's reeeeally loose with things like timing requirements. Just run a couple dozen instructions per "frame" in your game loop, then draw the screen somewhere, and you'll come close to playability for most of the sample games if your interpreter is bug free. It's the kind of project that with enough motivation you could complete in a week or so, which is why it's usually recommended for a first emulator project.
Once you have CHIP8 working somewhat, think about how you had to structure your code to make that work. Wouldn't the z80 CPU in a gameboy, or the 6502 CPU in an NES, also have opcodes just like the CHIP8 interpreter did? Surely you wrote a function for each CHIP8 opcode, so why not write a function for each z80 opcode, figure out how to read the gameboy's cartridge header, and see if your new CPU can run some instructions from Tetris? Once you get the code writing to VRAM, can you draw the tiles? What about the background? Build the emulator up piece by piece, and suddenly your game library is just chok full of little puzzle boxes, waiting to be tackled one by one.
It's very difficult to do all of this accurately, but don't focus on that right away. Just get it working, and learn about the system as you go.
There's a good IDE for it with a bunch more resources: https://github.com/JohnEarnest/Octo
CPSC 305: Computer Systems and Architecture
Using The Game Boy Advance To Teach Computer Systems And Architecture
I was thinking this would be trivial for something like a js emulator where you usually have a key array defined for storing keypresses.
If anyone knows of a GB emulator that already allows this please link to my comment.
(been writing a gameboy simulator for a few months now...)