Implement Match state object

[HappySunChild]

Implements #44

still ehh on the MatchPredicates table

[HappySunChild]

I've been deliberating about how to handle predicate ordering (state objects and literals as well, since they also sort of suffer from this). I've been thinking of allowing users to wrap their pattern keys in some function (not sure what to name it, maybe something like incr??) and that'd wrap it in a table that'd include some metadata such as the order it should be in. Then later after we've spooled up all the branches, we can sort them based off of whether they're wrapped and the associated priority they have. Could be interesting...

[HappySunChild]

I've been thinking about how to handle say wanting a state object (or predicate) pattern wanting to have priority over say another pattern in a lower tier. The suggested API in my previous comment could resolve this issue entirely, we could essentially completely discard the categorizing step and instead store all branches in an ordered array (sorting based off of type) prioritizing wrapped keys that contain their preferred priority.

This should still cause the keys to behave the same way, but now with the ability to more granularly define processing order!

[HappySunChild]

I've been thinking about how to handle say wanting a state object (or predicate) pattern wanting to have priority over say another pattern in a lower tier. The suggested API in my previous comment could resolve this issue entirely, we could essentially completely discard the categorizing step and instead store all branches in an ordered array (sorting based off of type) prioritizing wrapped keys that contain their preferred priority.

I've gone ahead and implemented this, but I'm still not sure about how to expose this API to the user cleanly. More exactly I'm not sure what to call the proposed "incr" function, and whether it should be directly access under ConFusion and not some sub-table within ConFusion (needs a descriptive yet short name).

Alternatively I've thought about just allowing users to define branches like this:

-- not actual valid code
match {
	{ 10, "its exactly 10" }, -- ordered list approach, pattern, value
	{ state, "its a state object" },
	{ GreaterThan(10), "more than 10" },
	_ = "something else", -- should this still be allowed for default branches?
}

This is nice and easy to implement, but for aesthetics and general intuitiveness it's absolutely horrific.

[HappySunChild]

might go with the proposed alternative design, it's ugly but its performant and is probably the easiest one to implement (plus doesn't pollute the export table with another function that has one specific usecase)