I can see you're a bit confused, so let me try and help: I've used BGB before to hack a couple of GB games.
Let's look at the debugger window and help you understand what each of the four windows are. The bottom-left window is the address space. For the CPU to read and write what's going on in the computer/console (the RAM, the ROM, other things) it needs an address space. The GB uses a Z80 CPU, which has a 16-bit address space: this means the most it can address is 64 kilobytes, or from $0000 to $FFFF. This space is shared by different things, and if you want to know precisely where everything is, you can look at a memory map.
Helpfully, BGB tells you exactly what the memory is mapped to at any given moment: in your screenshot you can see ROM0:0000, which means that that part of the address space is what's in ROM bank 0. 64KB isn't a lot to work with, so the GB uses bank switching to have bigger games (the NES does the same thing).
You'll notice that from $0000 to $7FFF, there are two ROM banks, usually 0 and 1, but the game can switch these at will during play - sometimes even during a single frame. After that you have VRAM (where the video information is stored); SRAM (kept on cartridges that need to save games, or just have a bit of extra RAM); WRAM (work RAM, the main RAM used by the console to do general stuff during a game); ECH (echo RAM, just echoes what the work RAM does); OAM (object attribute memory - sprites, in other words); an unused area; I/O (all the hardware registers that control different things like player input); and HRAM (high RAM, often used for regular things because it's a bit quicker than the work RAM).
Phew! Anyway, the top-left window is the actual game code. This is what's being executed to run the game, and is generally stored in ROM (usually bank 0 because that never changes). From left to right: the address; the bytes (opcodes) that are used for this instruction; a disassembly of that instruction; and a bit that I'm not sure about - maybe just a comment on each line? I don't know what the numbers mean, but it doesn't matter.
Top-right you'll see the current state of the Z80's registers. These are small bits of memory that the CPU uses to do things. For example, if you kill a baddie and get 100 points, the game might find the points value in ROM, load it to BC, load your current points to AF, add the two together, then store AF back to RAM.
The bottom-right is the stack: this is a temporary RAM area that acts like, well, a stack. You put something on top of the stack, and you can pull stuff off the top, too. It's commonly used by games because it's very fast - you can pile a whole load of things on the stack before pulling them off in quick succession. Sometimes when you're hacking, you need to find stuff that is on the stack.
So now hopefully you at least understand what you see, though I'm sure there are plenty of things you still need to know. Let me help you figure out that first idea you mentioned: giving two for a star instead of one.
Yes, you need the cheat searcher, so here's how to use it. I've never played the game so forgive me if I don't understand something...

Open the cheat searcher (it's a bad name, it should be a RAM searcher because it's not just for cheating), and search for an 8-bit value equal to 0 (because I guess you have zero stars at the beginning, right?). 8-bit values go up to 255, so I don't think you'll be needing to look for 16-bit values here.
Once you've done the search, you'll see a ton of RAM addresses with zero in them, so now go collect one star and now search for 1 instead of 0. See, what we've done is say "only show the addresses that had zero when I first clicked, and one when I clicked again", therefore severely limiting the possibilities. Go get one more star and search for 2. I'd be very surprised if you haven't narrowed it down to a single address, so assuming you have, right-click the address and go there in the debugger.
Remember that the Z80 is little-endian, so if you were to have more than 255, the larger byte would go second (i.e. 02 01 equals 258). Try changing the "02" you see to "09" or something, and see if the total in the game changes. If so, great! We know where the stars are stored in RAM, so now to change the code. This is the tricky bit, because you need to understand assembly, but it's not as hard as it sounds.
Right-click the address and "set access breakpoint", and add a breakpoint "on write" (because we want the game to stop when it writes to that address with the new star value). Now get another star and the game should freeze with the debugger on the instruction that's writing to the address.
Now, without actually doing it myself, I can't say what is going to happen.

But I can say that, unfortunately, this may be where you encounter the problem with this kind of hack.

See, there's an instruction on the Z80 that lets you add one to something, which is easier than saying specifically "add x amount to this". So changing 1 to 2 isn't easy, because you need a new instruction - and that instruction needs at least two bytes, unlike the INC command. Since you can't even move the code a single byte without crashing the game, you'll find it difficult to do this. There IS a way which involves jumping to an empty part of the ROM and putting the new code there, however, but I think this is enough for one day.

So, read what I said, play around a bit, and I hope you'll figure a few things out!
