Provide a robust plugin system for integrating new functions into the tservice.

Logic for getting and setting the context classloader we'll use for loading tservice plugins. Use `the-classloader`
to get the Classloader you should use with calls to `Class/forName`; call it for side effects to ensure the current
thread context classloader will have access to JARs we add at runtime before calling `require`.

The classloader is guaranteed to be an instance of `DynamicClassLoader`, which means we can add URLs to it at
runtime with dynapath; use `add-url-to-classpath!` to add URLs to the classpath to make sure they are added to the
correct classloader.

If you are unfamiliar with ClassLoaders in general, I found this article pretty helpful:
https://www.javaworld.com/article/2077344/core-java/find-a-way-out-of-the-classloader-maze.html.

Provide a robust plugin system for integrating new functions into the tservice.

Logic for performing the `init-steps` listed in a TService plugin's manifest. For plugins that specify that we
should `lazy-load`, these steps are lazily performed the first time non-trivial plugin methods (such as connecting
to a Database) are called; for all other TService plugins these are perfomed during launch.
The entire list of possible init steps is below, as impls for the `do-init-step!` multimethod.

Logic related to initializing plugins, i.e. running the `init` steps listed in the plugin manifest. This is done when
TService launches as soon as all dependencies for that plugin are met; for plugins with unmet dependencies, it is
retried after other plugins are loaded (e.g. for things like BigQuery which depend on the shared Google driver.)
Note that this is not the same thing as initializing *plugins* -- plugins are initialized lazily when first needed;
this step on the other hand runs at launch time and sets up that lazy load logic.

Plugin proxy used for plugins added at runtime. Load metadata from each plugin and register into the private variable.

Clojure implementation of the Semantic Versioning 2.0.0 spec. Parse, validate, sort and modify semantic version strings.

Why do I copy the code into the project? Cannot find the library from clojars.org anymore.
Please be aware that the copyright of this code belongs to owainlewis. You can access https://github.com/owainlewis/semver for more details.

Common utility functions useful throughout the codebase.

; Call these code in app entrypoint.
;; First Step
(setup-custom-namespace "tservice" :sub-ns "events")

;; Second Step (Call it when the app instance is launched.)
(initialize-events!)

; Defined in each event.
;; Define event handler
(defn- test-handler! 
   [{:keys [test-content]}]
   (println test-content))

;; Define events-init function.
(def events-init
  "Automatically called during startup; start event listener for test event."
  (make-events-init "test" test-handler!))

; When you need to trigger an event, call this code 
(publish-event! "test" {:test-content "This is a test."})

Provides a very simply event bus using `core.async` to allow publishing and subscribing to interesting topics
happening throughout the tservice system in a decoupled way. It's based on `metabase.events`.

## Regarding Events Initialization:

Internal Events: The most appropriate way to initialize event listeners in any `tservice.events.*` namespace 
(you can use [[setup-custom-namespace]] to change it) is to implement the
`events-init` function which accepts zero arguments. This function is dynamically resolved and called exactly once
when the application goes through normal startup procedures. Inside this function you can do any work needed and add
your events subscribers to the bus as usual via `start-event-listener!`.

Examples:

```clojure
; Call these code in app entrypoint.
;; First Step
(setup-custom-namespace "tservice" :sub-ns "events")

;; Second Step (Call it when the app instance is launched.)
(initialize-events!)

; Defined in each event.
;; Define event handler
(defn- test-handler! 
   [{:keys [test-content]}]
   (println test-content))

;; Define events-init function.
(def events-init
  "Automatically called during startup; start event listener for test event."
  (make-events-init "test" test-handler!))

; When you need to trigger an event, call this code 
(publish-event! "test" {:test-content "This is a test."})
```

External Events: If you use the event bus in plugin, you need to use [[make-events-init]] to 
generate event initializer and initialize the event in plugin configuration file.
When the above setting is successful, you can use publish-event! to trigger an event.