The benefit of this is that users only pay for what they use. If e.g.
only `vim.lsp.buf_get_clients()` is called then they don't need to load
all modules under `vim.lsp` which could lead to significant startuptime
saving.

Also `vim.lsp.module` is a bit nicer to user compared to
`require("vim.lsp.module")`.

This isn't used for some nested modules such as `filetype` as it breaks
tests with error messages such as "attempt to index field 'detect'".
It's not entirely certain the reason for this, but it is likely it is
due to filetype being precompiled which would imply deferred loading
isn't needed for performance reasons.

Value of 1 cannot be used, because users might set that in their vimrc
to _disable_ a provider, which would confuse :checkhealth and has().

Instead of deciding provider status in eval_has_provider, move the
decision to the provider Vim scripts.

Previously, provider loading worked as follows:

1. eval_has_provider() verified provider availability by searching for
   the provider#providername#Call function and cached this verificaion as a static
   variable for some providers
2. providers short-circuited on loading to prevent the definition of the
   Call function (with the exception of the node provider that did not)

This commit changes the expected interface between nvim and its
providers to facilitate provider reloading, by splitting the
verification of the provider from the availability of the Call function.

eval_has_provider() now checks for a provider#providername#enabled
variable. It is up to the provider script to set this to 0 or 1
accordingly. eval_call_provider() remains unchanged.

All providers hosting a Call function were updated to respect this.

The clipboard provider now has a Reload function to reload the
provider.

The exists('g:loaded_foo') convention is rather common, and may be
relied upon in some cases. It's also very unlikely that a user or plugin
has any reason to set g:loaded_foo to zero, so the principle of least
surprise can be brushed aside here.

https://github.com/neovim/neovim/issues/6107#issuecomment-279532143

Closes #6107