Type re-exporting similar to wally-package-types

[stravant]

Built a type re-exporting mechanism similar to wally-package-types directly into wally so that exported types from packages can be used by the consuming code. We cannot directly use the same approach as wally-package-types did for a couple of key reasons:

• wally-package-types relies on a source map to locate where the root module of the package is located. Wally packages do not generally include this source map out of the box. Instead, we will assume that Rojo is being used and extract the location of the root package from the Rojo project file. You could theoretically use Wally with something other than Rojo but this is not done and practice, and even if you did the fail case would simply be not getting re-exported types.

• wally-package-types takes an additional Luau parsing library dependency to do its work. This would not be an issue if Wally were regularly updated. However Wally is not well maintained, meaning that the type re-exporting code will ideally continue to work without needing future updates. If we used a Luau parsing library, that library would not understand future Luau syntax additions and failed parses for libraries using those new syntax features would break re-exporting.

• Instead, we use a flat permissive parse which tries to make as few assumptions as possible while locating the export type statements of interest. The core assumptions are that the Module contains valid Luau code and that additional types of string constant / comment syntax will not be added in the future. With these assuptions, we can strip out any non-code text in the form of comments / string constants, and then do a simple parse for export type statements.

• One additional complexity exists in the form of export type statements which depend on a non-exported type. In particular as a default type parameter. E.g.: export type Foo<T = NotExported> = .... To avoid this problem we strip out any non-exported default type parameters. That prevents syntax errors while still allowing the types to remain as usable as possible. Fusion is an example of a package that currently has this issue.

Note: I also had to update the reqwest package to a newer version as the current version runs into panics when built on an up to date rust toolchain.

Bikeshedding welcome on the what name the MODULE variable in the stub modules should be called.

[stravant]

• Updated insta to get tests back into a state where they build / run without issue.
• Added unit tests for the main extract_types logic.
• Added one integration test which installs a dependency that exports types.

With that I believe the PR is in a ready to merge state once it gets code review.