UX improvement: using real config file as spec and with --all-required flag

[abonander]

We've been using Typesafe-Config at work in a few projects now and we really like it; we've actually written very similar boilerplate code to what this library generates, and now having stumbled across it I'd like to use it instead.

However, because we've been using Config directly, all we have are actual config files that act as both reference/template and default; I am aware they can be used directly as specs for codegen with this tool but it generates code that assumes any given values in the config files are the defaults when I would like to just have them all be required values (so if they're modified later but a key is omitted or mistyped it throws an error instead of falling back to default).

I see this has already been sort-of discussed in #43 but I would say this is the "application" workflow that was mentioned; I would like to just use the default config as the spec, otherwise it's two separate files to keep in sync with each other with duplicated structure but one contains types while the other contains values.

I think this could be implemented as a flag like --assume-all-required or something which doesn't pull default values from the spec; it just uses them to infer the types of the fields.

[carueda]

(@abonander Thanks much for your input, here and in the other issues you have entered. I'm currently on vacation but will take a closer look in a couple of weeks. Thanks again.)

[carueda]

As just committed, the new --all-required flag will strictly force all entries (even objects) to be required (even the @optional annotation will be ignored).
This is now in a PR -- I'll do some further review, merge into master, and create a release hopefully within the next few days.