When the JS packages are being setup, type instances could require type information from packages which have not been setup yet. For example, list.List[Cat] could be defined inside the cat package and import the list package. The type instance List[cat.Cat] is initialized inside the list package. This will cause a failure because cat.Cat hasn't been setup yet since it requires list to be setup first as an import. We can't move List[Cat] to the cat package because List[T] may access unexposed data inside the list package.

This is the first part of two (or more) tickets. To solve the type initialization, each declaration will be given a group number. There will be $n$ groups and each group number is $g_i$ where $i \in [0 .. n)$. For any group, $g_i$, the prior groups, $\{g_0 ... g_{i-1}\}$, will have to be initialized first. All the declarations with the same group number are part of the same group. However within that group, the declarations will still need to be initialized in the current ordering where imports are done before importers and types are initialized before they are used in pointers, slices, etc.

This PR determines the grouping and order of the groups, then sets the group number for each Decl. This PR mainly consists of two new packages: sequencer and grouper. The sequencer is a generalized tool for determining ordering and grouping of items depending on the items' dependencies. The grouper stores information about the declarations' types so that it can use the sequencer to group and order the declarations based on type.

Following ticket(s) will use that group number to populate a "startup map" where the key is the group number and the value is a set of functions that need to be run. Each function will initialize all the Decls for a particular group for a single package. Then once all the packages have been added, the runtime will call each group of functions in order. The details still need to be ironed out.