1. Separate manifest and mod assembly loading.
	Manifest loading would be the first thing to happen when the program runs. (Or `Program.AssertMinimumCompatibility` would need to be moved after manifest loading.)
2. Add a 'ModType' to manifest.
	Probably optional, defaults to... whatever the default is called (standard? default? ...)
	When mod assemblies are loaded, only "load" ^
	If an invalid mod type, print an error.
	Possibly change up IMod/Mod/...
		IMod { Monitor, ModManifest, Entry() }
		BaseMod : IMod, IDisposable {}
		Mod : BaseMod { Helper, ... }
		The reason being that most things in IModHelper don't make sense for a core mod (or theoretical types such as XNB mods)
	Dependencies only make sense for the standard type. An XNB mod wouldn't depend on anything.
		Maybe move to other fields? Or IModManifest -> AssemblyManifest, ...
			Since 'EntryDll' woudln't make sense for things like an XNB mod either
3. Add the core mod type (or whatever it will be called)
	CoreMod : BaseMod { <func name for modifying game>() }
	At this point, it might be a good idea to have a separate 'manager' for each mod type? Or not?
	These are loaded immediately after manifests, so that they can process the SDV assembly.
Other:
	Do we want to allow multiple mod types? It would be convenient to have a mod be both a standard and core mod. However, core mods would have to be very careful not to touch classes/functions that reference the game itself.
		If not, we can check and enforce core mods not referencing the game.
	Possibly allow core mods to add new mod types? For example, Entoarox talked about doing simple Javascript mod support at one point. (Discord: search "in:#modding from: Entoarox#0580 Scripts", 3rd result)
		If so, possibly re-evaluate the previous point.
		I recall you not liking this idea before because of it blurring the line between mods and submods?
		Some other things that could use it (in theory, probably overkill for a lot of these): XNB loader (unless SMAPI adds support), Customize Exterior, Advanced Location Loader, Dynamic NPC Sprites, Custom NPCs/Critters/Farm Types/Furniture/Farming/...
			This would simplify things with mod managers at least.
			It would also provide a lot of power if multiple mod types are allowed
	A new ModBuildConfig would probably be a good idea for a core mod type - one that doesn't reference the game, but does reference Mono.Cecil
	...