Split vanillla object from levels allowing pruning vanilla assets on fast64 imports and managing vanilla objects independently of levels

[aglab2]

This PR introduces a new bank for vanilla objects split from the courses. This allows for the following nice improvements:

1. Vanilla objects can be used in multiple courses. For example it is common that binary hacks use TTC objects in multiple courses at once.

From level script it looks like

LOAD_VANILLA_OBJECTS(bob, generic),
...
JUMP_LINK(script_func_vo_bob),

2. Vanilla courses were setup in such a way that fast64 imports prune most of the useless vanilla leftovers. Level geolayouts/collisions/models were moved in *.inc.c that fast64 overwrites.

Unfortunately, this PR is very gigantic and I am not sure I can do much about reducing its complextity but I would really appreciate if I can get this merged to make handling vanilla stuff significantly more convenient.

[gheskett]

Important question, does this screw over 4MB users?

[aglab2]

Nope, in fact it should help 4MB users because levels will not have garbage in them with fast64 imports.

[gheskett]

Can you rebase this onto develop/3.0.0 instead of 2.3? This is very much major release territory.

[aglab2]

Rebased to develop/3.0.0. Original 2.3.0 commit is available at https://github.com/aglab2/HackerSM64/commits/split-levels-2.3.0-squash/

[gheskett]

Good grief, GitHub is really on the struggle bus with this one; I straight up had to skip the last entire quarter of files because GitHub stopped pre-loading diffs, and waiting for 200 them to load would literally take me all night.

[gheskett]

Send it :monkaS:

[aglab2]

Do not merge till PR Fast-64/fast64#356 is in main

[Lilaa3]

someone should really merge that honestly

[someone2639]

upstream fix seems to have been merged in so there should be no blockers here

[gheskett]

Is there anything else here to be added to fast64, especially now that HackerSM64 detection is a thing that actually exists?