Cleanup tfuncs

[Keno]

DAECompiler needs to extend builtin_tfunction to give additional information about how the tfuncs behave under DAECompiler's extended lattice. This is quite messy at the moment. We should clean it up in DAECompiler. However, I think it is also quite messy in Compiler, and I think if we had a clean story there, we could just copy it here.

I think there are a couple of contributors to the messiness in Base:

1. Part of the tfuncs are still using the tfunc dispatch table. The original intent of this was a performance optimization since intrinsics are just integers and many of the intrinsics are quite regular (min/max number of args, simple behavior, etc). However, I don't think this has quite panned out in practice. It also wasn't extended to the extended tfuncs (exct, effects, etc).

2. Speaking of extended tfuncs, it is fairly messy that these are separate - they should probably be merged so that there is one place that describes the behavior of these functions.

3. I think it makes sense to separate the intrinsics into some classes. E.g. there are the structural ones (getfield, tuple), runtime affecting ones, math ones, etc. I think logically separating these makes some sense and would make it easier to extend them in external absints.

I don't have a full view of what this should look like, but I feel that some cleanup in Base is possible and if it were done, the DAECompiler implementation would just fall out. Ideally we'd also have some testing utilities that would let us test completeness and alert us if new tfuncs are required.

[serenity4]

Regarding 1. specifically, would you suggest to get rid of all or only part of the following globals?

• N_IFUNC
• T_IFUNC
• T_IFUNC_COST
• T_FFUNC_KEY
• T_FFUNC_VAL
• T_FFUNC_COST

IIUC the intent would be to replace the use of some or all of these by f === <builtin> branches, essentially using this code structure.

[Keno]

I'm not fully sure. I think it might make sense to keep the table based approach for the arg counts. Otherwise, yeah, I think a big dispatch if is simplest - possibly with some sort of test infrastructure to make sure you've fully covered it.