JSDuck is really only meant for documenting JS and SCSS files.

Fixes #474

Avoid repeating option names as :foo and --foo.  Instead use a
function to transform from :foo to --foo.

Only leave the :title and calculate later the header from it in
Web::IndexHtml class.

Was broken since we implemented names for validators.

Always expect it to be an object with accessor methods.
As a default (and in tests) use OpenStruct.

So that the option name used inside JSDuck is the same as the --option
used on command line.

Rename the following:

* categories_path --> categories
* output_dir --> output
* template_dir --> template
* img_tpl --> img
* link_tpl --> link
* imports -->  import

Reset the defaults every time the Options::Parser#parse method is
called.  This allows us to re-use the parser which is slow to instantiate.

Some tests still need to re-instatiate the parser every time - move
these to a separate suite, so only the tests that need it will run
slower.

Implement full tests for them all.

Improve NullObject with the ability of values to be Proc's, which
will be invoked to provide more complicated logic.

Give names for all validators, so we can call them out by name in our
tests.

Add validator for :processes option.

Instead of calling optparser.on and opts.attribute directly, call
option and attribute methods that simply delegate to these objects.
This will also make it easier to refactor things in the future.

Eliminate the Validator class and attatch all the validation rules to
the Options::Record object, on which we can later simply call #validate!
to perform its own validations.

Previously the logic for this check was duplicated and sadly wrong.

So it hides all the internal options processing and we can use just
call this one static method in bin/jsduck.

Also turn the single Processor.process! method into a static one.

Instead format it right where it's actually needed: Web::IndexHtml.

Rename Options::Parser to Options::HelpfulParser - this is the class
that works like Ruby built-in OptionParser, but with improved --help
system.

Use Options::Parser as a name for the class that constructs the
OptionParser object and performs parsing with it, returning
Options::Record object.  While doing so, it tries to do little more than
setting of attributes on Options::Record - it handles converting
filenames to canonical form; reading file contents for --head-html,
--body-html and --css; reading and interpreting the --config JSON
file (and also auto-detection of the latter).

Options::Processor takes care of the rest: expanding filenames,
rendering the footer, configuring various classes, and validating
the options.

So related things sit closer together.

For example previously the --encoding option triggered immediate
setting of Util::IO.encoding attribute.  Now we store it to @opts
object initially and then afterwards inspect this object to apply
the real effects of the options.

Similarly with several other options.

Storing the actual options in a separate OptionsRecord while processing
them inside Options class.

Lots of changes because a myriad of instance variable references needed
to be changed to point at @opts record.

Created an #def_attribute method for creating an accessor for an option
and setting the default value.

Now the options are initialized close to where they are modified,
making the logic easier to see.

Make this options also in line with other multiple-path-accepting
options.

So it behaves the same as other options that accept multiple paths.

Refs #216

Yet another thing that's not really a concern for the TagRegistry,
as it only effects a small subset of tags.

As a result, the TagRegistry class is now quite clean.

Again, not generic enough functionality to keep in TagRegistry.