* Refactor entry point
* Remove unused code
* Reformat level header to be more clear, and add more comments
Looks like assembling with CMake will require some changes to the
assembler flags, and possibly some manual dependency specification.
* Less hard-coding when searching for libultra
* Proper compiler, assembler, and linker flags
* Multiple build types
* Support for multi-config generators
* When building with CMake, dynamic model lists are now generated
* Factored common code out of generate_*_list.js files to deduplicate
* Better separated generated model lists from main game code
`dynamic_asset_data.c` and `dynamic_animated_asset_data.c`
previously #included the corresponding generated headers, and
`dynamic_asset_loader.c` declared externs for the contents.
This messiness was likely done so the generated code would be built
automatically (the Makefile globs all C files under `src/`).
Now, model list data is output to C source files which are built
explicitly. This, with some refactoring, allows the previously
mentioned source files and externs to be removed.
This is a bit hacky in the Makefile but will be automatic under
CMake by using target properties.
* Reorganized some files under `tools/`
With CMake, the game version is stored in a generated header file so
dependencies on it are kept track of automatically.
The game now compiles when using CMake but does not link.
Generated code dependencies are not hooked up yet and corresponding
targets need to be built manually.
Incidental changes along the way:
* Move `export_level.lua` to `tools/level_scripts/`
* Small reorganizations/fixes to existing `CMakeLists.txt` files
* Support passing absolute paths to level export
Some parts need to be cleaned up/removed/streamlined after the CMake
build can build the game on its own and compatibility with what the
old makefile does is no longer needed.
