set a lower limit for size of literal unions we will do precise type inference of operations for

[carljm]

For example, we know that if we add Literal[1, 2] to Literal[3], we get Literal[4, 5]. But in some cyclic scenarios, something like x += 1 can result in an ever-expanding union (until we hit the Salsa cycle limit). We currently set an overall limit of 100 on literal-unions size, which is lower than the 200 Salsa cycle limit, but this still means we can iterate 100 times before we converge -- that's a lot.

We don't want to decrease our overall literal-unions size limit any lower than 100 (in fact ideally we'd increase it -- people should be able to explicitly create large literal unions). But we should set a much lower limit on the size of literal unions we are willing to do literal-math on (and beyond that limit we should just fall back to e.g. int). I think a limit in the low double-digits would be reasonable here. This would also significantly reduce the amount of fixpoint iteration needed in cyclic cases before we converge.

(This should apply not just to literal ints, but also operations on literal strings and bytes, too.)

[erictraut]

In case it's helpful, here are the conditions under which pyright performs literal math.

1. The operation cannot be in a loop (a for or while)
2. The operation must be acting on a local variable, as opposed to an attribute or subscript expression or a variable defined in some outer scope
3. The resulting union cannot be greater than 64 in size (a somewhat arbitrary number, but one that seems to work well in practice)

[carljm]

This would fix #660.

[MichaReiser]

Another instance of this:

class C:
    def __init__(self: "C"):
        self.x1 = 0
        self.x2 = 1
        self.x3 = 0
     
    def f1(self: "C"):
        self.x1 = self.x2 + self.x3
        self.x2 = self.x1 + self.x3
        self.x3 = self.x1 + self.x2

    def f2(self: "C"):
        self.x1 = self.x2 + self.x3
        self.x2 = self.x1 + self.x3
        self.x3 = self.x1 + self.x2