Split ExprSpecialNumber into separate literals, make 'value' optional

[sovdeeth]

Problem

ExprSpecialNumber made it a bit confusing to figure out that infinity/NaN values were present, wasn't a literal, and enforced the usage of value in every pattern, which was irritating. infinity should be just as valid as infinity value.

Solution

Replaces ExprSpecialNumber with three literals, LitInfinity, LitNegativeInfinity, and LitNaN. There didn't seem to be a nice reliable method to make a single literal have pattern-dependent values. It would be fine to have the value determined in init in most cases, but since every other literal doesn't require init to be called, it seemed unwise to rely on that.

The x value patterns have been replaced with x [value] and the negative and positive were added as prefixes for infinity.

Testing Completed

Existing tests suffice.

Supporting Information

In cases with no context, like set {a} to infinity, this changes behavior from using the infinity enchant to the value of infinity. Given that the enchant can also be referenced by infinity 1, I don't think this is a big issue. However, it's likely a lot more people use the enchant than the value, so we may want to explicitly maintain this behavior and allow positive infinity [value] and infinity value as the patterns.

---

Completes: none
Related: none

[erenkarakal]

infinity value sounds fine but value of infinity sounds a bit weird. maybe im too sleepy

[sovdeeth]

removed breaking changes by enforcing value if the only other keyword is infinity