 /**
 Driving engine of the message passing through the app, with no need for Delegate pattern nor Singletons.
 
-Coordinable will piggy-back on the UIResponder.next? in order to pass the message through UIView/UIVC hierarchy of any depth and complexity.
+It piggy-backs on the UIResponder.next? in order to pass the message through UIView/UIVC hierarchy of any depth and complexity.
 However, it does not interfere with the regular UIResponder functionality.
 
 At the UIViewController level (see below), it‘s intercepted to switch up to the coordinator, if the UIVC has one.

	private struct AssociatedKeys {
		static var ParentCoordinator = "ParentCoordinator"
	}
	///	*Must* be set for View Controller acting as Coordinator.rootViewController
	public var parentCoordinator: Any? {
		get {
			return objc_getAssociatedObject(self, &AssociatedKeys.ParentCoordinator)
		}
		set {
			objc_setAssociatedObject(self, &AssociatedKeys.ParentCoordinator, newValue, .OBJC_ASSOCIATION_RETAIN)

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
*/


///	Helper protocol to simplify coordinator‘s hierarchy walk-up.
///
///	Note: This protocol should not be subclassed.
public protocol Coordinating: class {
	///	Unique string to identify specific Coordinator instance
	///
	///	By default it will be String representation of the Coordinator's subclass.
	///	If you directly instantiate `Coordinator<T>`, then you need to set it manually
	var identifier: String { get }

	///	Returns either `parent` coordinator or `nil` if there isn‘t one
	var coordinatingResponder: UIResponder? { get }
}


///	Main Coordinator instance, where T is UIViewController or any of its subclasses.
open class Coordinator<T>: UIResponder, Coordinating {
	open let rootViewController: T


	/// You need to supply UIViewController (or any of its subclasses) that will be loaded as root of the UI hierarchy.
	///	Usually one of container controllers (UINavigationController, UITabBarController etc).
	///
	/// - parameter rootViewController: UIViewController at the top of the hierarchy.
	///
	/// - returns: Coordinator instance, prepared to start
	public init(rootViewController: T?) {
		guard let rootViewController = rootViewController, let rvc = rootViewController as? UIViewController else {
			fatalError("Must supply UIViewController (or any of its subclasses) or override this init and instantiate VC in there.")
		}
		self.rootViewController = rootViewController
		super.init()

		rvc.parentCoordinator = self
	}


	open lazy var identifier: String = {
		return String(describing: type(of: self))
	}()


	/// Parent Coordinator can be any other Coordinator
	open weak var parent: Coordinating?

	///	A dictionary of child Coordinators, where key is Coordinator's identifier property
	///	The only way to add/remove something is through startChild/stopChild methods
	fileprivate(set) public var childCoordinators: [String: Coordinating] = [:]



	open override var coordinatingResponder: UIResponder? {
		return parent as? UIResponder
	}



	/// Tells the coordinator to create/display its initial view controller and take over the user flow.
	///	Use this method to configure your `rootViewController` (if it isn't already).
	///	Some examples:
	///	* instantiate and assign `viewControllers` for UINavigationController or UITabBarController
