Up version to 0.17.0

Author: nsk90

buildSrc/src/main/kotlin/ru/nsk/Versions.kt

@@ -1,7 +1,7 @@
 object Versions {
     // library
     const val libraryGroup = "ru.nsk"
-    const val libraryVersion = "0.16.0"
+    const val libraryVersion = "0.17.0"
 
     // tools
     const val kotlin = "1.7.10"

docs/index.md

@@ -199,10 +199,11 @@ Local transition doesn't cause exit and entry to target state if target is a sup
 state.
 
 Use `type` argument or property of transition builder functions to set transition type:
+
 ```kotlin
 transition<SwitchEvent> {
-   type = EXTERNAL
-   targetState = state2
+    type = EXTERNAL
+    targetState = state2
 }
 ```
 
@@ -407,12 +408,13 @@ Notifications about finishing are available in two forms:
         }
     }
     ```
-    
+
    Transition for `FinishedEvent` is detected by the library and matched by special kind of `EventMatcher`,
    so such transition is triggered only for `FinishedEvent` that corresponds to this state.
    `FinishingEvent` generated by finishing of another state will not trigger such transition.
 
-   If `FinalState` that triggered `FinishedEvent` is also a `DataState` then its data field will be copied into `FinishedEvent`.
+   If `FinalState` that triggered `FinishedEvent` is also a `DataState` then its `data` field will be copied
+   into `FinishedEvent`.
    See [transition on FinishedEvent sample](https://github.com/nsk90/kstatemachine/tree/master/samples/src/main/kotlin/ru/nsk/samples/FinishedEventSample.kt)
 
 ## Nested states
@@ -500,8 +502,8 @@ createStateMachine(childMode = ChildMode.PARALLEL) {
 }
 ```
 
-There is no way to process multiple transitions for one event by using parallel states, only one transition may be
-triggered for each event.
+Currently, there is no way to process multiple transitions for one event by using parallel states, only one transition
+may be triggered for each event.
 
 ## Pseudo states
 
@@ -652,7 +654,7 @@ leads to undefined machine state and mixed notifications._
 
 Event though `KStateMachine` assumes that listener callbacks should not throw exceptions, it may happen in practice.
 If your app code throws exceptions in a listener callbacks library catches them, completes transition successfully and
-passes the first accured exception to `listenerExceptionHandler`. It simply rethrows exception by default, but you may
+passes the first occurred exception to `listenerExceptionHandler`. It simply rethrows exception by default, but you may
 want to mute them with custom handler for example.
 
 ### Other exceptions