- object with `toStorage` and `fromStorage` functions
  - `toStorage` is called after removing whitelist and blacklists and
    before serializing to JSON
  - `fromStorage` is called after deserializing from JSON

- so that these can work as examples and so that their order is very
  explicit as they're treated like any other transform internally

- create new transforms/ directory that will hold all built-in
  transforms moving forward
  - and export them in transforms/index.ts

- more importantly, makes the logic a little simpler / easier to read

- describe usage, link to MST snapshots, show typings, and link to
  internal examples of whitelist and blacklist transforms
  - use commit permalink for internal transforms so it won't 404 or
    change over time (though ofc will need to be updated if the
    transforms API changes)
- describe ordering and show a small diagram of it end-to-end

- more because we added whitespace and split up functionality, not
  because transforms are in any way a big code addition (~15 LoC)

- the array passed into the transforms should be required
  - same for arrToDict function
  - they're now called only when array is defined, and I think that
    behavior is more intuitive -- it should error if the array isn't
    defined
    - (test): in internal usage, they're never undefined, so this was
      reducing coverage because it was dead code
    - if the transforms were to eventually be externally visible /
      import-able, they should definitely throw an error in that case
      too -- if external users pass undefined to it
      - and the typings change means it'll happen at design-time too
      - definitely think it's more intuitive for external users this
        way too

- (docs): use this commit for w/blist transform examples
  - or a variant of this commit -- just one where arr is required

- yay back to 100% code coverage now!
  - there's a transform branch missing bc there's no test case where
    there's something in storage and at least one toStorage-only
    transform
    - but covering this else branch doesn't really matter

- create some transform fixtures
- abstract out a setItem function

- should consider splitting the tests and fixtures into separate files
  soon, esp now that we have a few different test suites here

- not necessarily the most useful transforms there, but they are
  examples nonetheless
  - and they show both to and from Storage usage

- now docs are roughly same size as source
  - and README is getting a bit unwieldy, thinking about splitting the
    Transform docs into their own file