CODINGCONTRACT: Move internals to a separate folder

[G4mingJon4s]

Currently, all of the cct code is scattered all over the place. Now all relevant parts are in one folder.

I also moved the contract types into sub-categories, since working with one big file is pretty messy. If this change isn't desired, I can revert that commit.
Also, the categories the types have been moved to are up for debate. Some categories are not really self-explanatory and some contracts don't really fit in their categories IMO.
Things like "optimizations" is a really broad term, so I'm not sure if it really fits?
And contracts like "Total Ways To Sum" aren't really optimization problems. I moved them there, since most of those problems are dynamic programming problems. Suggestions are always welcome!

Side node: git mv didn't really work on the data/codingcontracttypes file. Not sure if I messed that up somehow?

[d0sboots]

High-level comment: If we aren't going to have all the contacts in one big file (and that seems reasonable), then we should do one per file, with the possible exception of contacts that are tightly related to each other. And name them according to the contract name (or an appropriate representative, in the case of multiple.)

[G4mingJon4s]

That should be all errors ironed out. I tested every contract for functionality just in case using this script.

[d0sboots]

One thing that I am not super enthused about is the amount of boilerplate that is accumulating here. Originally, if you wanted to add a contract type, you just added it to the file. The name and impl were in one place, done.
After your last change, that became several places: The name needed to be added to the enum (duplicated in NetscriptDefinitions), also the type signature in nsdefs, as well as the entry in the map. But, most of those seem unavoidable in exchange for the type-safety and exposing the list of contracts as an enum, so OK.
Now, there's several new places this has to be repeated (a barrel file, the Pick<> in each file), and it's not getting us any new functionality. It's just in pursuit of splitting one file up into several. It's starting to become worryingly large.

[G4mingJon4s]

I get what you mean.
I can't really do anything about the duplicate definition of the enum, that's a problem the enum approach generally has.

Defining the type-signature in the nsdefs removes the need for satisfies SimpleCodingContractType in the definitions itself. It might be a bit annoying that it's not all in one file, but the benefits outweigh the negatives for this aspect IMO.

Now, the split could be designed a bit differently, if the boilerplate is too much. The barrel file is not needed, since all of the types should probably never be used somewhere other than ContractTypes.ts.
I chose a Pick typing for every file to clearly indicate what contracts should be defined in each file. It's always an option to go back to satisfies Partial<CodingContractTypes>. I could also abstract that typing away a bit and just have a helper like CodingContractTypePicker<CodingContractName.FindLargestPrimeFactor>.

Currently, adding a new contract would require these changes:

• Add the name in the nsdefs enum and the enum in the CodingContract folder
• Add the type-signature in the nsdefs
• If needed, add a new contract file and add that to the barrel file and the total definitions
• Add the contract type description, data etc.

The main pain point is probably step 3, since all others are basically the same, just not all in file.

Your call here, I'm fine with all approaches honestly.

[d0sboots]

If we could autogen the barrel (import * from contracts/) that would be the biggest win. The rest is mostly minor. See if you can think of something clever, otherwise I guess this is fine (the benefits to reading outweigh the boilerplate in writing)

[G4mingJon4s]

So, I played around with auto-gen stuff for a bit. IMO it's not really worth it, it just doesn't feel right to me. Instead, I removed the barrel file entirely, since the only place where these definitions are needed is the ContractTypes.ts file. If any file, like a test file or anything else wants to use all solvers, they can just import all solvers via that file.
I think this is ready to be merged now.