Added entry & exit function support

[rkoshy]

The changes allow each state to have an _entry and an _exit handler that acts as a special transition that executes on entry into, or exit from a state.

[illarionvk]

I like the @enter/@exit naming schema.

Would it also make sense to omit those internal-use actions from the final machine methods, i.e., the machine should not have machine.enter() and machine.exit() methods?

[krasimir]

@illarionvk what are your concerns about having those defined. They'll be actually @enter and @exit.

[illarionvk]

The camelcasing transform would rename the methods to .enter() and .exit(), wouldn't it?

I think having literal non-camelcased machine['@enter'] methods is ok, as long as the developer can define their own, explicit, enter/exit methods too:

const noop = function() {}

const config = {
  state: IDLE,
  transitions: {
    [IDLE]: {
      "@exit": function() { ... },
      init: function() { ... }
    },
    [INITIALIZING]: {
      "@enter": function() { ... },
      noop
    },
    [READY_TO_PROCESS]: {
      enter: function() { ... }
    },
    [PROCESSING]: {
      exit: function() { ... }
    },
    [DONE]: {
      noop
    }
  }
};

// The config should produce an instance similar to the type below
type MachineInstance {
  ...Machine,
  '@enter': () => void,
  '@exit': () => void,
  'enter': () => void,
  'exit': () => void,
  'init': () => void,
  'noop': () => void,
}

[rkoshy]

I'm fine dealing with the last bit but can you add a test coverage of the changes.

Yes @krasimir I will add the tests.

[krasimir]

@illarionvk is completely right. We have to think about how the API will look like. The helper here will indeed remove the @, which is not necessary a bad thing but it shouldn't be exposed the same way the other actions are. I'll need to think it through. @rkoshy I'll try finding some time to explore more your PR.