Added external transitions to readme and removed an unnecessary check…

… in Transition.getDomain.

makina-compiler/src/xyz/colinholzman/makina/Transition.kt

@@ -19,7 +19,6 @@ data class Transition(val activeLeafState: State,
 
     fun getDomain(): State? {
         return if (kind == Target.Kind.DEFAULT
-                && !source.isLeafState()
                 && target.isDescendantOf(source))
             source
         else

readme.md

@@ -62,7 +62,7 @@ state open {
 The state `closed` now has an handler for the event named `open`. The handler causes the machine `Oven` to transition from `closed` to `open`. The full syntax for an event handler looks like this:
 
 ```
-on <event-id> [(<guard>)] [<action>] [-> <target>];
+on <event-id> [(<guard>)] [<action>] [->|--> <target>];
 ```
 
 The things in angle brackets can be arbitrary identifiers that conform to the C language concept of an identifier. Things in square brackets are optional. In the case above the handler includes an optional transition target, but not a guard or action.
@@ -82,6 +82,8 @@ All actions and guards are implemented by the user as C language functions with
 int <function-name>(struct <machine-name> *, struct <machine_name>_event *);
 ```
 
+Transition targets can be default  (`-> <target>`) or external (`--> <target>`). Default transitions behave like a [local transition](https://statecharts.github.io/glossary/local-transition.html) in the event that the target state is a descendant of the source state and like an [external transition](https://statecharts.github.io/glossary/local-transition.html) otherwise. External transitions always behave like an external transition, i.e. they always cause the source state to exit.
+
 ### Hierarchical States
 
 To avoid duplicating event handlers for similar states Makina allows you to define sub states that defer unhandled events to their parent states. The `closed` state of the oven machine might have a few sub states: