 	Adds new child coordinator and starts it.
 
 	- Parameter coordinator: The coordinator implementation to start.
-	- Parameter callback: An optional `CoordinatorCallback` passed to the coordinator's `start()` method.
+	- Parameter completion: An optional `Callback` passed to the coordinator's `start()` method.
 
 	- Returns: The started coordinator.
 	*/



	/// Default identifier is the class name of the Coordinator
	var identifier: Identifier {
		return String(describing: self)
	}

	/// Parent Coordinator
	var parent: Coordinator?

	///	essentially an array of child coordinators
	private(set) var childCoordinators: [Identifier: Coordinator] = [:]



	/// - returns: Coordinator instance, prepared to start
	init(rootViewController: RootController?)

	/// The root view controller for a coordinator. 
	///	Each coordinator creates its VC hierarchy internally, so this is read-only property (post init)
	var rootViewController: RootController { get }

	///	Unique identifier for the Coordinator
	var identifier: Identifier { get }
}


/**
Coordinators are a design pattern that encourages decoupling view controllers
such that they know as little as possible about how they are presented.

As such, view controllers should never directly push/pop or present other VCs.
They should either use:
1. Delegate pattern to indicate such action is needed and owning Coordinator will assign itself delegate
2. Specific closures that owning Coordinator will populate and thus respond to
3. Custom actions implemented using `targetViewController(for:sender:)` API

Coordinators can be “nested” such that child coordinators encapsulate different flows
and prevent any one of them from becoming too large.

Each coordinator has an identifier to simplify logging and debugging.
Identifier is also used as key for the childCoordinators dictionary

You can either use Coordinator instances directly or – far more likely – 
subclass them to add specific behavior for the given particular usage.

Note: Don't overthink this. Idea is to have fairly small number of coordinators in the app.
If you embed controllers into other VC (thus using them as simple UI components), 
then keep that flow inside the given container controller.
Expose to Coordinator only those behaviors that cause push/pop/present to bubble up
*/
public class Coordinator<T>: CoordinatorType {
	///	This
