* ns API is wrapped once
* when a new workerscript is created, each layer of ns is stamped with a private workerscript field that allows the functions to work.
* Test has been refactored to account for new method of wrapping
* BREAKING: ns functions need access to `this` value of their parent ns layer (or any ns layer)
* Enums are passed directly to player (no cloning) but are frozen.
* Add specific types for sleeve tasks
* Moved LocationName enum to overall enums file
* Add LocationName enum to those provided to player
* remove trailing s on CompanyPosNames enum (now CompanyPosName, in line with LocationName)
* Also regenerated all ns documentation. This leads to an expected error when checking for generated files, because PRs should not normally touch markdown files. Also leads to a lint failure in generated file bitburner.d.ts
* also removed some exporting from NetscriptDefinitions.d.ts for anything that wasn't imported somewhere else.
* Add support for enums at other ns layers
* APIWrapper: simplified wrapping algorithm and modified to just use cloneDeep to copy enums instead of recursively wrapping enums as if they were new API layers
* Improve APIWrapper typing
* Changed some typings at RamCostGenerator to allow for enums at different levels without enums needing a ram cost
* Added enums to ns.corporation, removed getter functions that were being used instead.
* Add FactionWorkType for player use
* Add ClassType and CompanyWorkPos enums
* Change netscriptDefinitions to expect members of these new enums where appropriate.
* Instead of hardcoded categories, automatically walk through all layers of ns, check for their associated costs, and check that ingame static and dynamic costs match the expected assigned costs.
* RamCostGenerator will have an error if ramcosts are defined for nonexistent functions, in addition to error if not all functions have ram costs defined
* Removed a few random blank comment lines in NetscriptDefinitions.d.ts
* RamCalculation.test.ts checks exact expected static and dynamic ram usage from (almost) every function, based on defined RamCosts in RamCostGenerator.
Cypress and Jest both define "expect", but they come from different
libraries (Cypress uses Chai, Jest uses its own thing). So we can't
include both of them in the tsconfig.json. Conveniently, however, we
don't need any of the test code to be part of the main project, so
it suffices to give these things their own tsconfig.json files.
That being done, adding "jest" to the global types lets us remove all
those imports.
Cypress and Jest both define "expect", but they come from different
libraries (Cypress uses Chai, Jest uses its own thing). So we can't
include both of them in the tsconfig.json. Conveniently, however, we
don't need any of the test code to be part of the main project, so
it suffices to give cypress its own tsconfig.json file.
That being done, adding "jest" to the global types lets us remove all
those imports.