Adds @moduledoc and @doc blocks to functions, including ## Examples

[fireproofsocks]

The big takeaway here is that your package IS compatible with releases -- the documentation just needs to clarify that.

This PR attempts to add more documentation per #39

• Adds ## Examples sections to many functions
• Shows a usage example of how to set this up to be compatible with releases
• Removes confusing references to "serverless" -- despite invoking an unrelated technology, how values are stored (or even if they are stored at all) is an implementation detail, and not one that needs to be documented because it is "behind the interface".

[iloveitaly]

Why did you remove this line? I think this is a helpful guide to using this in prod that doesn't seem to be reproduced in the other documentation you added.

[fireproofsocks]

😬 Eeep -- I confess that removal wasn't entirely intentional (attempting to work at home through too many distractions); the overall push was to point to the module docs for more info.

However, the important thing I was trying to get at is the method by which the variables are loaded. E.g. parsing .env files or running Mix.Task.run("loadconfig") from inside your application.ex should be unnecessary: by the time code in your application.ex is executed, the config ship has sailed. The config has already loaded and any code in them has already been executed (that's true for regular mix or for release execution). It's a simpler tie-in without the concerns re mix vs. releases or GenServers if the .env files are parsed in the config files (likely in runtime.exs). The examples outlined in the "Usage Suggestion" in the moduledoc covered the strategy that I think is the more effective one.

To illustrate one example, let's say I wanted to use System.fetch_env!/1 in my configs to enforce that a specific env variable had to be set. If I am loading an .env file (and setting system envs) in application start, it's too late: the app can never actually start unless I happen to have manually set that ENV elsewhere because System.fetch_env!/1 will raise an error before code in application.ex gets a chance to run. In order to work around loading the .env inside of the application start, I would have to soften up any reading of system env vars in my config files by using System.get_env/2 instead, which weakens the contract.

This starts to touch on what I wanted to run by you with a PR for issue 43.

I should say that any of these ideas are just fodder for discussion -- no worries if they don't seem like a good fit.