Migrate File/Object Functionality to Prototype

[agilgur5]

E.g. execute shouldn't be called from the executor and passed in an automaton, it should be a function on the automaton's prototype. getCentroid() should be part of the regions's prototype (and possibly stored in the returned region object somewhere too). etc.

[agilgur5]

I actually left them all as functions because they're pure and can just be called from a module (which now they are split into). For ease of use, it might make sense to also allow the ability to bind all the functions to an object, i.e. a function that modifies an object with all the methods bound to it. Not sure if worthwhile or makes sense, but this is an interesting problem as it's nice to have the simplicity via OO-style but then you lose out on some benefits of the functional paradigm ¯\(ツ)/¯

[agilgur5]

Having written a decent bit of Go in recent years, Go's receiver methods seem to massage the gap between these two pretty well (except when they can be called on nil, which is pretty confusing (see also argoproj/argo-workflows#12228, argoproj/argo-workflows#11451)).

There isn't quite a neat analog in JS, but optionally binding functions or 1 level of currying has somewhat similar ergonomics