Runtime: allow re-usable functions across a workflow

[josephjclark]

It's fairly common in implementation to have to use the same helper function in multiple jobs. Water-aid, for example, defines a very complex function called convertToLocalCurrency which is duplicated in two jobs.

We need to be able to declare a function somewhere, and re-use it across multiple jobs. This probably plays into the unit-testing story too.

The difficulty of course is that if you write a function to state, it'll be destroyed at the end of the job when the state is serialised

[josephjclark]

Quick brainstorm of options:

• Allow the runtime to safely serialise functions. OR some functions. You should be able to decompile a function down to its source code, right? How does that work and can we exploit it? Then we can write functions to state and pass them downstream. This is a bit of a fiddly UX though because if you return state downstream, you could lose the functions entirely. Also I think writing logic to a state object feels like an antipattern
• That means we have to import the custom functions into the job.This might make the compiler's life harder because it has to distinguish adaptor functions from user functions (and what if there's a conflict?)
• One solution is to use a convention. If there's a file called utils.js - or perhaps a path to a utils file is on the workflow object (yes I like this), we can add import * as util from './utils' into each job. Now the exports from each job are available on a utils object. So you can do utils.convertToLocalCurrency. I quite like this: it's achievable at low cost and adds a lot of utility. We need the right word for utils. Maybe the workflow can map it to whatever variable you like.