Planning around usage as a library

As you know, Python's builtin tokenizer, parse tree, AST, bytecode, stack frames and much more is directly available to use as importable python modules. This has in-turn made it much easier to create tools like `flake8` and `pyupgrade` directly on top of them.

It would be very helpful to keep a similar spirit in mind when developing `pyrefly`, both as a Rust crate and as a Python package, providing for eg. direct Python functions to be able to extract full/partial import graphs, data flow graphs, generated SSA, inferred types etc. as directly accessible Python objects. It helps other tools very easily extend the core functionality provided by the package in ways that would fall completely out of the scope of this project, but nevertheless use the exact same base tools.

A good example would be writing an optimizer: having strictly checked type information available programmatically can help write automations to inline certain functions, replace loops with comprehensions, and other such changes with complete confidence in the runtime behaviour not changing.

Another example would be automatically finding and deleting dead code in an application codebase, based on which functions are referenced within the codebase and which simply aren't.