Improve CLI docs (#1404)

* Improve CLI docs

* Fixed all the typos (hopefully).
* Improved the bad English. This encompasses grammar, vocabulary, generally awkward phrases, etc. The result is easier to read and understand, and in some cases shorter.
* Made some formatting improvements. This includes making formatting more consistent, but I changed some of it to be better, at least in my opinion.
* Removed certain unnecessities, the biggest one being the commands documentation. I think this is unnecessary because of the `dx --help` command. It also needs to be updated every time a command gets added/updated/removed. It doesn't really provide much extra insight than `dx --help`.
* Improved plugin documentation. I added a warning to ignore all of it, which is ironic, but the fact is that plugins are probably going to change. But by the time I learned that, I already made some changes to the plugin docs. This includes a better guide on how to get started (although still bad since the plugin system is too messy), and some general changes like the aforementioned English or formatting.
* And more. I can't list it all, but I didn't use any destructive changes. The content might be reformatted (to be shorter or easier to understand), but the meaning isn't lost.

* Fix grammar in packages/cli/docs/src/creating.md

Co-authored-by: Evan Simkowitz <esimkowitz@users.noreply.github.com>

* Update README.md

* Change config example

---------

Co-authored-by: Evan Simkowitz <esimkowitz@users.noreply.github.com>

packages/cli/docs/src/plugin/README.md

@@ -1,24 +1,85 @@
-# CLI Plugin Development
+# CLI Plugin development
 
-> For Cli 0.2.0 we will add `plugin-develop` support.
+**IMPORTANT: Ignore this documentation. Plugins are yet to be released and chances are it won't work for you. This is just what plugins *could* look like.**
 
-Before the 0.2.0 we use `dx tool` to use & install some plugin, but we think that is not good for extend cli program, some people want tailwind support, some people want sass support, we can't add all this thing in to the cli source code and we don't have time to maintain a lot of tools that user request, so maybe user make plugin by themself is a good choice.
+In the past we used `dx tool` to use and install tools, but it was a flawed system.
+Tools were hard-coded by us, but people want more tools than we could code, so this plugin system was made to let
+anyone develop plugins and use them in Dioxus projects.
 
-### Why Lua ?
+Plugin resources:
+* [Source code](https://github.com/DioxusLabs/dioxus/tree/master/packages/cli/src/plugin)
+* [Unofficial Dioxus plugin community](https://github.com/DioxusPluginCommunity). Contains certain plugins you can use right now.
 
-We choose `Lua: 5.4` to be the plugin develop language, because cli plugin is not complex, just like a workflow, and user & developer can write some easy code for their plugin. We have **vendored** lua in cli program, and user don't need install lua runtime in their computer, and the lua parser & runtime doesn't take up much disk memory.
+### Why Lua?
 
-### Event Management
+We chose Lua `5.4` to be the plugin developing language,
+because it's extremely lightweight, embeddable and easy to learn.
+We installed Lua into the CLI, so you don't need to do it yourself.
 
-The plugin library have pre-define some important event you can control:
+Lua resources:
+* [Official website](https://www.lua.org/). You can basically find everything here.
+* [Awesome Lua](https://github.com/LewisJEllis/awesome-lua). Additional resources (such as Lua plugins for your favorite IDE), and other *awesome* tools!
 
-- `build.on_start`
-- `build.on_finished`
-- `serve.on_start`
-- `serve.on_rebuild`
-- `serve.on_shutdown`
 
-### Plugin Template
+## Creating a plugin
+
+A plugin is just an `init.lua` file.
+You can include other files using `dofile(path)`.
+You need to have a plugin and a manager instance, which you can get using `require`:
+```lua
+local plugin = require("plugin")
+local manager = require("manager")
+```
+
+You need to set some `manager` fields and then initialize the plugin:
+```lua
+manager.name = "My first plugin"
+manager.repository = "https://github.com/john-doe/my-first-plugin" -- The repository URL.
+manager.author = "John Doe <john.doe@example.com>"
+manager.version = "0.1.0"
+plugin.init(manager)
+```
+
+You also need to return the `manager`, which basically represents your plugin:
+```lua
+-- Your code here.
+-- End of file.
+
+manager.serve.interval = 1000
+return manager
+```
+
+And you're ready to go. Now, go and have a look at the stuff below and the API documentation.
+
+### Plugin info
+
+You will encounter this type in the events below. The keys are as follows:
+* `name: string` - The name of the plugin.
+* `repository: string` - The plugin repository URL.
+* `author: string` - The author of the plugin.
+* `version: string` - The plugin version.
+
+### Event management
+
+The plugin library has certain events that you can subscribe to.
+
+* `manager.on_init` - Triggers the first time the plugin is loaded.
+* `manager.build.on_start(info)` - Triggers before the build process. E.g., before `dx build`.
+* `manager.build.on_finish(info)` - Triggers after the build process. E.g., after `dx build`.
+* `manager.serve.on_start(info)` - Triggers before the serving process. E.g., before `dx serve`.
+* `manager.serve.on_rebuild_start(info)` - Triggers before the server rebuilds the web with hot reload.
+* `manager.serve.on_rebuild_end(info)` - Triggers after the server rebuilds the web with hot reload.
+* `manager.serve.on_shutdown` - Triggers when the server is shutdown. E.g., when the `dx serve` process is terminated.
+
+To subscribe to an event, you simply need to assign it to a function:
+
+```lua
+manager.build.on_start = function (info)
+    log.info("[plugin] Build starting: " .. info.name)
+end
+```
+
+### Plugin template
 
 ```lua
 package.path = library_dir .. "/?.lua"