The type names (measurement, percentage, ...) don't currently fit
into JSDuck view of the world.  Just turning this off for now to
avoid excessive amount of needless warnings.

The xtypes property now basically reflects the alias property in
Ext.define class definition. It's a hash with structure like:

    xtype: {
        widget: ["text", "textfield"],
        feature: ["blah"]
    }

When rendering the class header "widget" is mapped to "xtype",
"feature" to "ftype", "plugin" to "ptype".

Explicit @xtype foo is converted to xtypes: {widget: ["foo"]}

The choice of names is currently misfortunate.  It would be logical
to use "alias", but we already have @alias which does a completely
different thing.  This issue has been disturbing us for long, but
now it really starts to hurt.  I feel we have to reclame @alias
from its current occupating and use some other tag like @include
to replace @alias.

Instead just put the .json file directly into output dir.

That's the sensible behaviour one would expect from something
that's called a JSON export.

Everything extends Object anyway, but pulling the methods of Object
into every other class just pollutes the docs with too much info.

Renamed js_classes/ to js-classes/ to conform to the overall naming
convention.

- Remove trailing whitespace.
- Document types of properties.
- More corrections to constructor docs.

For all classes except Object, remove docs for prototype and constructor
properties.  These make more sense when documented only at Object level.

   foo: Ext.baseCSSPrefix + "name"

will be interpreted as:

   foo: "x-name"

Render meta-data section at the bottom of class documentation.

Treat @author and @docauthor as meta-tags.
For these tags strip e-mail addresses from content.
For now this ability is not supported for user-defined tags.
Probably some formatting will be useful for custom tags too - I'd
just like to gather some real-world usage info on this, so marking
this option currently as experimantal.

Allows detecting Ext.define and Ext.extend when Ext is wrapped
inside another namespace and the code uses Foo.define instead.

Oh, what a silly mistake...

At the moment just hard-coding the version, but I'd like to find
a better approach, so I could store the version number in only one
place, say, the gemspec file.

Over time we have used localStorage for favorites and history which
are no more, but the entries to localStorage remain.  Time to clean up
before we hit a size limit.

Bad regex caused {local_storage_db} to be left unreplaced.
It managed to match "{localStorageDb: {local_storage_db}" for
which it didn't find any replacement.

Now with stricter regex such errors should be no more.

Takes care of the silly case where member contains no other
documentation than a @deprecated tag.

Mostly useful for developers outside Sencha.

Use "" instead of null for baseCls cfg.

Created JsDuckRunner class inside the Rakefile to manage all the
options we are passign to JSDuck.

Instead of a myriad of different tasks, rake -D now only lists 4:

- sdk
- touch
- gem
- spec

sdk and touch tasks accept arguments to allow creation of live and
export versions. For example:

    $ rake sdk[live]

Ensure it's run before all the main export tasks.

Also run it before :sdk task.

This task is now run *before* other tasks.  So we first compress
the contents of template/ dir into template-min/ and from then on
use the template-min/ dir as our template.

To perform sencha build, I added build-js.html file that is like
template.html but contains only bare minumum of JavaScript links
that we need to build into one file.

The purpose of all this is to run the :compress before building
gem for release version of JSDuck.  For this reason we also don't
concatenate data.js with app.js, as the jsduck gem wants to generate
its own data.js.

The default value for --template option is now "template-min/",
only in development related tasks :sdk and :touch do we replace
it with "template/".