fix scfg_ext_7 handling with direct boot

[edo9300]

With the scfg permissions update, melonds changed the default scfg flags when direct booting, but as default it disabled access to the scmc registers, breaking direct booting homebrews and software that required nand access.
Properly handle this case by using the appropriate dsi header field in the rom containing the arm7 scfg settings (as stated on gbatek, only bit 0,1,2,10,18 and 31 are to be considered).

[edo9300]

After the initial commit, I noticed that retail games failed to boot, this came down to the fact that before they were being booted with unlocked scfg, and sdk5 games have a routine that checks for that, and, if it's unlocked, automatically populate the ram values used by the sdk to determine the environment it's being run on, which should instead be taken care of by the launcher.
The routine in question is this (here taken from pokemon black at arm7 address 0x238018c):

void setup_scfg(void) {
	if((REG_SCFG_EXT & SCFG_EXT_SCFG_MBK_REG) == 0)
		return;
	REG_SCFG_WL |= 1;
	REG_SCFG_CLK |= SCFG_CLK_TOUCH;
	REG_SCFG_EXT |= SCFG_EXT_NDMA;
	*(unsigned*)0x380FFC4 = REG_SCFG_EXT;
	unsigned r0 = REG_SCFG_OP & 0xFF;
	r0 |= (REG_SCFG_A9ROM & 0x03) << 2;
	r0 |= (REG_SCFG_A7ROM & 0x06) << 4;
	r0 |= (REG_SCFG_WL & 0x01) << 7;
	*(unsigned char*)0x380FFC8 = r0;
	
	r0 = REG_SCFG_JTAG;
	unsigned r12 = r0 & SCFG_JTAG_DSP_ENABLE;
	r0 |= r12 >> 6;
	
	unsigned r1 = REG_SCFG_CLK;
	r12 = r1 & 0x7;
	r0 |= r12 << 3;
	r12 = r1 & (SCFG_CLK_TOUCH | SCFG_CLK_NWRAM);
	r0 |= r12 >> 1;
	*(unsigned char*)0x380FFC9 = r0;
	REG_SCFG_EXT &= ~SCFG_EXT_SCFG_MBK_REG;
}

Specifically the games seems to only need the values of SCFG_ROM to be placed in ram so that they can detect if they're run on a ds or on a dsi