These changes have been discussed in doom-neovim#233.

As a side note, I ran stylua and luacheck over the repo.

* From everyone's perpective

- The module structure has been flattened out, removing the category
  grouping. Beyond less iteration scopes, this may help with, in the
  future, allowing the user to write and enable custom modules in
  $DOOMDIR.

* From the user's perpective

- `doom_config.lua` works via overrides now, it can change defaults
  on the global `doom` before everything gets actually configured.
- `doom_modules.lua`  just returns the actual thing it's supposed to,
  without {return value}.source. More on that next.
- Instead of each config file returning a source key with its file
  location, the handlers for each config file actively search for them.
  This is described in the respective files inside `lua/doom/core/config`,
  but it's basicaly a check for two special paths falling back to
  runtimepath.
- `doom_userplugins.lua` is removed in favor of having its
  functionality in `doom_config.lua`. To add a standalone package, add
  its packer spec to `doom.packages` (this is a map-like table of
  package names to packer specs).
- To override the spec of a module package, change the keys in
  `doom.packages[package_name_without_author]`.
  Special attrs: `config` is run after the built-in config.
- To change settings and behavior, override keys in
  `doom[module]`, or just `doom.*` for some core features.
- To add standalone bindings, add them to `doom.binds`. This is
  passed to nest along with the modules' binds. `doom.binds` overrides
  anything you don't like in modules, you can safely replace the bind.
- To add standalone autocmds, add them to `doom.autocmds[augroup_name]`. The
  structure is as passed to `utils.create_augroups`, so:
  ```lua
  doom.autocmds[group_name] = {
    { event1, pattern1, cmd1 },
    ...
  }
  ```
- You shouldn't override any tables, like `doom.autocmds` or `doom.packages`,
  only the leaves, else you remove all that is already there. We could
  use metatables to avoid this in the future.
- The `config.nvim` table is no longer used, most of its functionality is spread
  elsewhere, like autocmds. For variables and options, just use
  vim.opt.*, vim.g.* etc. in `doom_config.lua`
- Settings can also be appended to in `doom_config.lua`, because
  defaults are prepopulated.

* From a maintainer's perpective

- Most things are grouped under the `doom` global, which is populated
  and overriden early in `init.lua`. The exception is enabled modules,
  which you still need to require `doom.core.config.modules` to get.
  However, do so sparingly, and only if you truly mean to iterate over
  enabled modules disregarding user overrides (they may have removed a
  particular package or reset binds).
- Modules are defined in the following folder structure inside
  `lua/doom/modules`:
  `<module>/{init.lua,packages.lua,binds.lua,autocmds.lua}`.
  init.lua and packages.lua are required, even if empty.
- `init.lua` returns: defaults under a `defaults` key; config functions
  under `packer_config[package_name]`. It can access the doom global
  only inside the configs.
- `packages.lua` returns: a map of package names to package specs, with no
  `config` or `disable` keys present. Most things should be lazy-loaded,
  preferably with the `cmd` and `module` keys. It cannot access the doom global.
- `autocmds.lua` returns: a list of autocmds to be applied under the group
  `doom_{module}`. It can use the `doom` global to add things
  conditionally.
- `binds.lua` returns: the keyconfig to be passed to nest. It can use the
  `doom` global to add things conditionally.

What's left:

- Implement lsp wrapping.
- Document the individual modules.
- Write a migration script.

This adds wrapping of lsp for one language: lua.
It adds two modules, `auto_install` and `lua`. The former toggles auto
installation, and is sort of a marker module. Beyond installing and
configuring nvim-lsp-installer and DAPInstall.nvim, it doesn't really do
anything. It's purpose is to be checked on the lua module which will use
the installers if it is enabled. Otherwise just falls back to $PATH. Since
I'm on NixOS, I can only test the non-auto installation, but it seems to be
downloading properly for the auto version. The lua module also installs
additional packages, namely lua-dev.nvim, which used to be part of the lsp
module. It could add keybinds, but I couldn't think of any. It has a
special autocommand that `dofile`s the config.lua, which actually sets
up lsp (and possibly dap) lazily and only after the first lua file is
opened. This commit is meant as a template/prototype to other language
wrappings.

Also remove the built-in modules in favor of putting them inside utils
(reloader and async) or implementing them later with the new module
structure (others).

Now supports lua functions. The ideas come from @caligian and his repo, though
modified to use a unique index instead of requiring a name.

Previously ran on BufNewFile,BufRead.

Fixes issues with the kommentary module and provides new behaviour such
as `gcA` to add comment to end of line.

This replaces broken `nvim-tree-docs`.

Previously, some modules would cause packer errors by depending on
packages of disabled modules. This fixes that behavior.

It is more up to date and well maintained than my own, plus includes
what I had implemented.

This is sometimes allowed, but here it would try and get things that
weren't initialized.