Add matches and nested APIs

[matthewp]

This PR adds the following APIs:

• <service>.matches(<string>)
  Returns true when the <service> is in the state named <string>, which includes nested states separated by dots ('.'); e.g. foo.bar indicates state foo in the toplevel machine and bar in the current child machine.
• nested()
  Creates a state, similar to state, immediate and invoke; this state executes a child state machine

Closes #56

[HipsterBrown]

This looks great! 👏 I also like the included nested helper for quickly creating child machines. 💯

Looks like the bundlesize just needs to be updated to get CI green. I wonder if it's possible to feed that bundle size data into the website, i.e. "Fast 1.48kb functional library for creating Finite State Machines"

[gkiely]

@matthewp is there some additional work you would like to implement on this branch or is it able to be merged in?

If you'd like this merged, I'd be happy to address the conflicts and get it ready for review.

[matthewp]

@gkiely feel free to update the branch. I would like to take another look before we release it though. This might make a good 1.0 feature.

[matthewp]

This PR also needs docs before merging. And a changeset.

[ehuelsmann]

@matthewp I would have added .matches() and nested in separate changes, but I don't feel strongly about it. I think both additions to the API are valuable. Before we merge, I think it's necessary to add documentation to docs/{guides,api}. (Before we forget.)

[ehuelsmann]

@matthewp going into the "multiple states" part of #56, you may consider .matchesAny(...stateNames) which iterates over state names calling .matches() until one returns true, or, given that .matches() isn't part of the API yet, simply make it variadic.

[matthewp]

I probably would break it up too. I actually think I feel better about matches than I do the nesting stuff. I need to get back around to finishing this. Want to keep it open as to not forget.