Moving calc functions to methods where possible

[PgBiel]

This issue intends to track the progress of migrating calc functions to methods in int and float, as well as other types.

The main reasons behind this effort are to improve organization of those functions - e.g. calc.binom is specific to ints, so it would make sense to invoke it as int.binom instead, much like other operations we have today like sign and bitwise operations -, but also to allow for new, more concise - but optional - syntax (e.g. 5.rem(40) is equivalent to int.rem(5, 40)).

PR #3489 started this effort, in a very general way, attempting to migrate all calc functions to methods.

After several rounds of discussion over Discord, it currently seems wiser to avoid doing that for the moment. In an initial phase, we should consider just migrating methods which unambiguously belong to either int or float, such as int.binom or float.sin. Later on, we could decide how to deal with methods which work with a diversity of types (namely min, max and abs) as well as methods which have differing behavior for ints and floats (such as pow). They could stay in calc as needed, or in more than one place at once; that'd require further discussion.

[laurmaedje]

sin in particular also operates on angles, so that's something to consider. I like the clean approach of having things as methods, but the arguments in the forge thread against it were also convincing.