Split FunctionValue out of Applicable

[Calvin-L]

This is a refactoring-only change, and therefore very low-priority. But, it fixes a longstanding and (to me) irritating lack of type safety surrounding functions and operators.

---

The Applicable interface is widely used, but it is "confused" because functions and operators both implement it, even though those entities have very different capabilities and cannot be interchanged in TLA+.

This commit adds a new FunctionValue interface so that TLC's code can distinguish between operators (OpValue) and functions. Despite adding a new interface, the split actually REDUCES the number of non-comment lines of code in TLC.

A few qualitative notes about why I think this is a good refactor:

1. Operator values have to implement getDomain() even though they do not have a domain. Therefore, knowing that a value is Applicable is not enough to prove at compile-time that it supports every Applicable method.

2. Similarly, all operator values have to implement select(), but all of them throw an exception.

3. Code blocks that cast objects to Applicable are overly reliant on SANY's checks to ensure that the correct kind of value flows there.

4. Operators and functions behave differently when called with more than 1 argument: operators can have arity > 1, but functions have to wrap the arguments in a tuple.

Note that Applicable has been retained because it is still widely used in the community modules. I hope that once the community modules switch to using FunctionValue and OpValue correctly, we can completely remove Applicable and the other now-deprecated methods.

I have documented the key methods of FunctionValue and OpValue as well as I can; Applicable has no documentation I could find.

[lemmy]

There are other pending changes in the CommunityModules that would make CM incompatible to older versions of TLC. At some point (today?), we could and should decide that new CommunityModules releases depend on a current version of TLC.

[lemmy]

LGTM