todo(is): restructure modules into categorized subfolders

[nberlette]

TODO: restructure the @type/is source files into categorized subfolders

The current structure of the @type/is project is a mostly flat folder full of files,
spanning a wide range of different topics and purposes. This not only makes it difficult
to maintain the project, but also makes it difficult to navigate the hierarchy of its
source code in even the most mundane of ways.

This is a tracking issue for my goal to restructure the package into a more organized,
categorized format, grouping together the modules based on the general purpose or API
they are a part of. These groups will roughly align with the synthetic directories that
already exist as entry points in the package manifest, except they will actually exist
in those locations on disk.

When all is said and done this should prove to be a much more intuitive pattern than the
current project structure...which is really starting to feel claustrophobic with the
roughly ~160+ modules all living in the same ./src folder.

Related Tasks and Notes-to-Self

• Relocate unit tests from a parallel ./tests folder into the same locations as
  their corresponding source files. This will make it much easier to jump between a
  source file and its unit tests, and will also make it more obvious which files are
  missing unit tests.
  • Current Structure (disjoint):
    • ./src/iterable-iterator.ts
    • ./tests/iterable-iterator.test.ts
  • Updated Structure (grouped):
    • ./src/iteration/iterable-iterator.ts
    • ./src/iteration/iterable-iterator.test.ts
• Decide on a consistent naming convention for the new source directories.
  • should ./iterable.ts, ./iterator.ts, ./iterable-iterator.ts be grouped
    together in an ./iterable folder? Or ./iterators? Or ./iteration? 🤔
• Use snake_case for filenames, and kebab-case for module entrypoints.
  • currently kebab-case is used for both and it bothers me way too much
• Decide on a consistent format / convention for module entrypoint variants.
  • e.g. ./weak-map.ts is exposed as ./weak-map, ./weakmap, and ./weak/map.
    This pattern quickly becomes hard to manage when its applied to nearly 200 files.
• Split the single ./_internal.ts file into granular submodules within ./_internal/
• FUTURE: implement an "extension" API to support cherry-picking of individual groups
  to include in the primary is namespace. (is this idea even feasible? it sounds neat,
  potentially allowing "lite" / custom "builds" of the library. we'll see.)
• Improve documentation for all modules and their submodules
• Consider the future assertions variants of each type guard, which will be generated
  from the existing type guard functions. How will this new project structure impact it?