feat: 🎸 Expose extension config to modules (#1279)

* feat: 🎸 Expose extension config to modules

Currently, only the preRegistration hook receives the extension's
configuration as a parameter. Providing getModuleFn's with the
extension's configuration, and all lifecycle/modules with the
application's configuration as rootConfig should open the doors to more
configurable extensions.

Closes: #1268

* CR Update: Pass extension and service config through extension manager preinit/getmodule

* CR Update: Remove appConfig from servicesManager

* CR Update: Remove appconfig variable

docs/latest/extensions/index.md

@@ -193,7 +193,8 @@ today, create a GitHub issue!
 
 The `ExtensionManager` is a class made available to us via the `@ohif/core`
 project (platform/core). Our application instantiates a single instance of it,
-and provides a `ServicesManager` and `CommandsManager`.
+and provides a `ServicesManager` and `CommandsManager` along with the application's
+configuration through the appConfig key (optional).
 
 ```js
 const commandsManager = new CommandsManager();
@@ -201,6 +202,7 @@ const servicesManager = new ServicesManager();
 const extensionManager = new ExtensionManager({
   commandsManager,
   servicesManager,
+  appConfig
 });
 ```
 
@@ -210,8 +212,8 @@ The `ExtensionManager` only has a few public members:
 - `registerExtensions` - Registers an array of extensions
 - `modules` - An object containing registered extensions by `MODULE_TYPE`
 
-During registration, lifecycle hooks and modules have access to
-`ExtensionManager`'s `ServicesManager` and `CommandsManager`.
+During registration, lifecycle hooks and modules have access to the extension's config,
+the application's config and `ExtensionManager`'s `ServicesManager` and `CommandsManager` instances.
 
 Our `@ohif/viewer` uses the `modules` member to access registered extensions at
 appropriate places in our application.