Savestates would be the easier option, though I would at least do the first bit to figure out a bit about the save format as you could then use an external editor (many programs, including GBA emulators themselves if they support Lua, can be used to fiddle with memory -- it is how a lot of external cheat programs like emuhaste, artmoney and such like work) rather than fiddle with what I presume is a horribly clunky GBA interface.
Anyway you probably want to find where the custom level data is stored in memory (easy enough to find -- just sit there editing one block over and over whilst leaving everything else the same and it should be able to be found using a basic cheat search https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
There are two primary ways to store level data that games use.
1) Coordinates. X, Y, item type sort of thing. What it is you get to figure out but should not be too hard if you just make the same block one to the right, and then one up in an editor, and then change the type of block. Some will have a further variable like sub item type or direction, other times items pointing in different start directions will be entirely different items despite being identical on the graphics front.
2) "Bitmap". Every thing represents one "cell" in a level (might be pixel level, might be 8x8 pixels, might be more, might be something a bit more custom). If there is nothing there then it is blank. Takes a bit of space but easy and used in a lot of things, can see it for something as simple as mario vs donkey kong too.
Things may be in layers, and you can combine the two methods (have seen various things where the background is bitmap but the pickups were coordinates). Naturally there can also be oddities like certain items have a basic location but take up much more on screen, and weird things like the bottom of the level is a run of cells but the data in them contains a height and type command but enough of that.
Anyway so now you found the location and type of data you can work on getting the saves to copy it and restore it.http://www.advanscene.com/
says all versions of this game use Flash v131 - 512kbit which is nice -- pokemon has a 1024kbit save and various flash carts pump it up again if you want them to. Either way hopefully there is some space available in the save, indeed I am not sure what Mario vs Donkey Kong has to save to justify that kind of save chip to begin with. If not you get to figure out how to change it to be the 1024kbit version (see how SRAM patching works and tweak it slightly so, might not even need that if it is one type of flash to another).
Now when saving you get to have it also grab your level data and stick that in the save data. This will be an assembly trick but not necessarily a big one -- whatever is reading data into the flash location you tell to go grab the level data as well, or maybe trigger your own write to a choice location.
You might have to stop it erasing your level as well. If you know where it is in RAM you can use a debugging emulator like no$gba debugger to set a break on write to that location to see what overwrites it when you leave, hopefully it is a simple memory wipe and nothing else is bothered but if it is a proper wipe because something needs the space then back to the reading and writing the save when in the editor.
I have also not mentioned hashes but cross that bridge as and when -- short version is games to make sure nothing got corrupt or deter unsophisticated cheaters will do a mathematical operation (the simplest example is take all the numbers that make up the data, add them all together, if the result is the same as the one written down also next to the save then it is presumably OK), depending upon how much you are colouring outside the lines with the save then your edits might make it think it is corrupt.
This is all getting fairly obtuse. There was a fairly nice discussion a while back when someone was looking to make the high score table for gameboy tetris be saved and restored. Data is data so basically the same idea and thus might be worth looking that up.
Option 2. Normally seen in things like NES games where the devs when porting it out of Japan were too cheap to pay for save data on the cart and instead left the saves out or went password but the code was still there, just slightly hidden so normal usage would not call it. Hackers then come along, dust it off and put it in its rightful place. I mention it only because if the level editor is still present in code (somewhat odd to see for the GBA as things were often compiled rather than assembled and it is easy to comment out code) then save functionality might also still be present and potentially able to be restored by a further patch.