Refactor/pure functions

[SamKG]

@kmantel @jvesely this is a draft of the pure transferfunction refactor - I could definitely use some input on if this is a good approach, or any other suggestions.

autocompiled udf code isn't in this draft yet - i want to completely nail down pure functions first

[lgtm-com[bot]]

This pull request introduces 16 alerts and fixes 17 when merging c5ee9e2bdcc5f38563a94e67cc7eaa7841c782ce into aabefefdce6be85a7ae7a6879faa4d1fa3d1f6a1 - view on LGTM.com

new alerts:

• 9 for Comparison using is when operands support `__eq__`
• 3 for Unused local variable
• 2 for Duplication in regular expression character class
• 1 for Except block handles 'BaseException'
• 1 for Variable defined multiple times

fixed alerts:

• 16 for Unused import
• 1 for Duplication in regular expression character class

[lgtm-com[bot]]

This pull request introduces 1 alert when merging c5ee9e2bdcc5f38563a94e67cc7eaa7841c782ce into 11ccd547effc95997f61d4d95f103e834a3c9d24 - view on LGTM.com

new alerts:

• 1 for Except block handles 'BaseException'

[jvesely]

Other than the few design issues. This is missign two major design justifications:

1.) Can all Functions be converted? What about the likes of DDI, ContentAddressableMemory? If the compiler needs to be improved to handle those, converting TransferFunctions just removes cases that are easily supported and can be targeted as intermediate steps.

2.) How is the new design going to be enforced? Is every new Function expected to conform to the new format? If so what kind of help/guidance/enforcement will there be to guarantee that? Will there be a need for similar cleanup every time few more Functions are added?