[docs] Update info about buildCreationArguments method

Author: nsk90

docs/pages/persistence.md

@@ -42,7 +42,7 @@ can be configured with `EventRecordingArguments` properties.
 
 ```kotlin
 val machine = createStateMachine(
-    creationArguments = CreationArguments(eventRecordingArguments = EventRecordingArguments())
+    creationArguments = buildCreationArguments { eventRecordingArguments = buildEventRecordingArguments {} }
 ) {
     // ...
 }

docs/pages/statemachine.md

@@ -32,7 +32,8 @@ val machine = createStateMachine(
 ```
 
 By default, factory functions start state machine. You can control it using `start` argument.
-All overloads accept optional argument `CreationArguments` which allows to change some options.
+All overloads accept optional argument `CreationArguments` which allows to change some options. 
+Use `buildCreationArguments()` function to provide it.
 
 Subsequent samples will use `createStateMachine()` function, but you can choose that one which fits your needs.
 

docs/pages/states/states.md

@@ -269,7 +269,7 @@ block to have a valid state references for transitions.
 Keep in mind that states are mutated by machine instance, defining them with `object` keyword (i.e. singleton) often
 makes your states live longer than machine. It is common use case when you have multiple similar machines
 that are using same singleton states sequentially. Library detects such cases automatically by default
-(see `autoDestroyOnStatesReuse` argument of `CreationArguments` structure) and cleans states allowing for future reuse.
+(see `autoDestroyOnStatesReuse` property of `CreationArguments` interface) and cleans states allowing for future reuse.
 You can disable automatic machine destruction on state reuse, and call `StateMachine.destroy()` manually if required,
 or just do not use `object` keyword for defining states.
 If you have your own `DefaultState` subclasses that are singletons and has data fields, use

docs/pages/transitions/transitions.md

@@ -256,7 +256,7 @@ to previous state (except target-less transitions).
 This API might be called as many times as needed.
 To implement this feature library stores transitions in a stack, it takes memory,
 so this feature is disabled by default and must be enabled explicitly using
-`createStateMachine(creationArguments = CreationArguments(isUndoEnabled = true))` argument.
+`createStateMachine(creationArguments = buildCreationArguments { isUndoEnabled = true })` argument.
 Other words this feature works like stack based FSM.
 
 Undo functionality is implemented as `Event`, so it possible to call `undo()` from notification callbacks, if you use