* BREAKING CHANGE: Removed getSleeveStats and getSleeveInformation because this info is provided by getSleeve in a more usable form.
* BREAKING CHANGE: Removed tor, inBladeburner, and hasCorporation fields from ns.getPlayer. Functionality still exists via added functions ns.hasTorRouter, ns.corporation.hasCorporation, and ns.bladeburner.inBladeburner.
* Separated ns definitions for Person, Sleeve, and Player interfaces with both Player and Sleeve just extending Person.
Added getSleeve, which provides a Sleeve object similar to getPlayer.
* Renamed the sleeve ns layer's interface as sleeve lowercase because of name conflict. todo: May move all the ns layers interface names to lowercase for consistency
* Added ns.formulas.work.crimeSuccessChance and reworked to allow both sleeve and player calculations.
* Removed internal Person.getIntelligenceBonus function which was just a wrapper for calculateIntelligenceBonus. Any use of the former in formulas creates a conflict where ns-provided Person objects throw an error.
* Renamed helpers.player to helpers.person for netscript person validation. Reduced number of fields validated due to Person being a smaller interface.
* Fixed bug in bladeburner where Player multipliers and int were being used no matter which person was performing the task
* Fixed leak of Player.jobs at ns.getPlayer
* Person / Player / Sleeve classes now implement the netscript equivalent interfaces. Netscript helper for person no longer asserts that it's a real Person class member, only that it's a Person interface. Functions that use netscript persons have been changed to expect just a person interface to prevent needing this incorrect type assertion.
Reverted ToastVariant back to an enum internally. Still exposed to player as just possible strings.
Changed all 1-line documentation comments to actually be 1-line. Moved some because they were not providing documentation for the thing they were trying to.
Makes the Datamancer skill for Bladeburner apply to the Population Estimate change of the Tracking contract. If this was not desired, then the description of Datamancer needs to be made more accurate :D
The off-by-one error was in the original sum, so it's not obvious
in the simplified version of the sum. Fixing this greatly improved
the accuracy of the simple calculation for small counts, but I'm
leaving the recursive mode in. Maybe I'll lower the threshold,
though. 100 isn't a terribly small number.
Threw something together with a formula that should, for large
purchases, be roughly the same cost as normal. The formula change
may cause noticeable deviation from expected costs for low numbers
of upgrades, though, so I plan to fix that by having high
quantities handled differently than low ones if necessary.
