docs: port docs to https://docsify.js.org/#/

Author: galargh

.gitbook/assets/Logo_Testground_color_dark_vert.svg

@@ -0,0 +1,5 @@
+* SDKs
+  * [Go](https://github.com/testground/sdk-go)
+  * [Rust](https://github.com/testground/sdk-rust)
+  * [JS](https://github.com/testground/sdk-js)
+  * [Nim](https://github.com/status-im/testground-nim-sdk)

.gitbook/assets/Logo_Testground_color_light_vert.svg

@@ -2,11 +2,9 @@
 
 ![](.gitbook/assets/image%20%283%29%20%281%29.png)
 
-{% hint style="info" %}
-You are reading the Testground documentation for the [master](https://github.com/testground/testground) branch.
-
-The Testground team maintains documentation for the `master` branch and for the latest stable release.
-{% endhint %}
+> You are reading the Testground documentation for the [master](https://github.com/testground/testground) branch.
+>
+> The Testground team maintains documentation for the `master` branch and for the latest stable release.
 
 ## Overview
 
@@ -66,7 +64,7 @@ The Testground project was started at Protocol Labs because we couldn't find a p
 * Comparative testing 🌖
 * Backwards/forward-compatibility testing 🌖
 * Interoperability testing 🌑
-* Continuous integration 🌑 
+* Continuous integration 🌑
 * Stakeholder/acceptance testing 🌑
 
 ### 📄 Simple, normalized, formal runtime environment for tests
@@ -121,7 +119,4 @@ Emit and collect/export/download test outputs \(logs, assets, event trails, run
 
 ## Documentation issues
 
-{% hint style="warning" %}
-**This docs site is work-in-progress!** You're bound to find dragons 🐉 in some sections, so please bear with us! If something looks wrong, please [open a docs issue](https://github.com/testground/testground/issues/new?assignees=&labels=docs&template=DOCS.md&title=docs%20site:%20%3Cdescribe%20the%20problem%3E) on our main repo.
-{% endhint %}
-
+!> **This docs site is work-in-progress!** You're bound to find dragons 🐉 in some sections, so please bear with us! If something looks wrong, please [open a docs issue](https://github.com/testground/testground/issues/new?assignees=&labels=docs&template=DOCS.md&title=docs%20site:%20%3Cdescribe%20the%20problem%3E) on our main repo.

.gitbook/assets/Logo_Testground_symbol_color_light.svg

@@ -47,4 +47,3 @@
 * [docker:go](builder-library/docker-go.md)
 * [exec:go](builder-library/exec-go.md)
 * [docker:generic](builder-library/docker-generic.md)
-

.gitbook/assets/Logo_Testground_symbol_onecolor_dark.svg

@@ -30,9 +30,7 @@ Most build failures are caused by a problem with the plan code rather than the b
 
 when using the `docker:go` builder, plans are build using a standard template. This template is typically all that is needed, but for some plans, the default docker build may be too inflexible. For cases such as this, the Dockerfile can be extended to include custom directives.
 
-{% hint style="info" %}
-If you want to just provide your own Dockerfile, use the `docker:generic` builder instead.
-{% endhint %}
+?> If you want to just provide your own Dockerfile, use the `docker:generic` builder instead.
 
 This feature is best explained by showing how it works. This is the default Dockerfile the `docker:go` builder will use to build plans. Notice that this is a go template. The template has a few points where customizations can be added.
 
@@ -112,6 +110,3 @@ post_runtime_copy   = "RUN echo 'at post_runtime_copy'"
 See an example plan which uses a customized Dockerfile, see [here](https://github.com/testground/testground/tree/master/plans/dockercustomize)
 
 Interested in how this works? All the Testground builders can be seen [here](https://github.com/testground/testground/tree/master/pkg/build)
-
-
-

.nojekyll

@@ -4,11 +4,9 @@ The Testground runtime revolves around a traditional daemon/client architecture,
 
 This architecture is flexible enough to run the daemon within a shared cluster, with many users, developers, and integrations \(e.g. GitHub Actions\) hitting the same daemon to schedule build and run jobs.
 
-{% hint style="info" %}
-At the moment, we do not run Testground in shared-cluster deployments; most developers spin up personal Kubernetes clusters, and run both the daemon and the client on their own development machines, pointing the local daemon to the remote k8s API.
-
-However, as of Testground v0.5, **we do support running the daemon within a Kubernetes cluster as a pod.** This capability is vital to pave the way for shared-cluster deployments, which will enable much more efficient resource utilization and CI workflows.
-{% endhint %}
+> At the moment, we do not run Testground in shared-cluster deployments; most developers spin up personal Kubernetes clusters, and run both the daemon and the client on their own development machines, pointing the local daemon to the remote k8s API.
+>
+> However, as of Testground v0.5, **we do support running the daemon within a Kubernetes cluster as a pod.** This capability is vital to pave the way for shared-cluster deployments, which will enable much more efficient resource utilization and CI workflows.
 
 ## Testground Daemon
 
@@ -63,4 +61,3 @@ You can also wait for the task completion when building or running by appending
 ```text
 $ testground build single --plan=example --builder=exec:go --wait
 ```
-