Add extract_overlay.py and dependency files submodule

[ProjectOblivion]

No description provided.

[JoshSchreuder]

@Xeeynamo I think we should consider removing make-config.py in favour of this

I have used it for CAT and ARE now and I think it improves upon a lot of the new config adding experience.
Probably this would close #2703 and #2942

[ProjectOblivion]

Beyond what was there for cat and are, it now also automatically imports and merges e_init.c (EntityUpdates and EInits) and header.c (it has generated <ovl>.h for a while now).
It uses the dynamic syms process and does not use the previous git checkout method for handling symbols, though it does still use git add when complete, to prevent the new config/ files from being wiped by make clean, and uses git clean to clean the asm directory. There is no longer a chance for accidental losses that would happen in the past.

[Xeeynamo]

I’m a bit surprised to see a project-specific utility recreated and relicensed in a separate repository, then proposed as an external dependency rather than contributing improvements upstream. Any changes to make_config.py or closely related tools should also be coordinated with the existing contributors (CC @hohle).

From a practical perspective, I’m not sure what the advantage is of pulling sotn_utils in as a submodule, given that it can already be cloned and used independently. A quick look at the repository also shows several pieces of hard-coded logic that are tightly coupled to our decomp (https://github.com/ProjectOblivion/sotn_utils/blob/main/sotn_config.py, https://github.com/ProjectOblivion/sotn_utils/blob/main/sotn_overlay.py, https://github.com/ProjectOblivion/sotn_utils/blob/main/symbols.py). Ideally, these should be driven by a configuration file rather than embedded directly in the code.

I want to avoid the inevitable situations where updating our project's configuration or symbol definitions require opening PRs in a separate repository, waiting for review, and then syncing the changes back. Such friction will only slow us down and make maintenance more complicated.

[ProjectOblivion]

waiting for review, and then syncing the changes back. Such friction will only slow us down and make maintenance more complicated

This is the primary reason it is in a separate repository, so this doesn't happen to me. I'm updating it incredibly frequently, on the order of daily at times. I do not want everything that is currently in the repo to remain in the repo, though, I want some things to be in sotn-decomp and I am in the process of splitting it up, but that takes time.

Ideally, these should be driven by a configuration file rather than embedded directly in the code.
This is my ultimate intent, but it isn't there yet. I wanted to get it available and worry about things like that next.

I tried having it just be cloned and used independently, but I first created this tool months ago and the only one who used it aside from myself was @JoshSchreuder .

should also be coordinated with the existing contributors

I've brought the tool up twice on discord and have gotten little in the way of overall response there. @JoshSchreuder has been fantastic with feedback and @hohle gave me some good points to adjust (of which I believe I've adjusted all of his concerns). I don't appreciate being told to coordinate when I've done my absolute best to do just that long before submitting the PR.

[Xeeynamo]

I've brought the tool up twice on discord and have gotten little in the way of overall response there. @JoshSchreuder has been fantastic with feedback and @hohle gave me some good points to adjust (of which I believe I've adjusted all of his concerns). I don't appreciate being told to coordinate when I've done my absolute best to do just that long before submitting the PR.

I wasn't aware you coordinated with the other contributors. A mention of in the pull request description would have helped me. I am simply sharing my feedback based on my data points, which I have none as your pull request description is blank.

[hohle]

I've used the tools as well and have commented on that repo. It works well. I'm torn on it being in the repo or not.

I'm not sure what the advantage is to being a submodule vs moving into the repo. The tool can be iterated on separately, but still requires a commit back to sotn-decomp for everyone else to get those changes. It doesn't get other contributors changes any faster and makes updates more opaque.

[ProjectOblivion]

While much of the code is sotn specific, some of it is not. I am working toward splitting them apart, but there are a lot of places where things could go sideways. I don't have any particular desire to have the sotn specific stuff outside of sotn-decomp, but it is particularly frustrating to put time and effort into something that gets forgotten because it isn't in the repo, then essentially being told it shouldn't be a part of the repo.