Now comments like:

        /**
         Some text here
	 Another line.
	 */

are handled as the author intended.  Previously this text would have
been parsed by Markdown as code-block as it's indented.  Now we remove
the indentation also at the beginning of these lines that don't begin
with '*'.

Also include --builtin-classes option to short help message.

Added example of usage.

By default showing the short help, so we don't scare users.

--help=full will show all possible command line options.

Only render the constructor method as "new ClassName".

Refactored handling of required configs.  They now have required=true,
instead of former optional=false which was a bit awequard.

- This @tag only applies to methods.
- Rendered it in method signature just like @protected.
- Added small info-div explaining the purpose of template methods.

Now that we have a guide in wiki covering all the new syntax I don't see
a need for this file any more.  I think the source code of Ext JS 4
itself will in the future serve as a good real-world example.

Instead of reading in all files from SDK/touch/src dir - all these
files aren't really used by touch.

The classes list in Touch docs looks much more sensible now.

Add separate rake task :jsb for updating the file.

This is to make it possible to build docs app in a server that
doesn't allow running "sencha create jsb" command.

The generated methods will have the following documentation:

    @cfg foo

    @method getFoo
    Returns the value of {@link #cfg-foo}.

    @method setFoo
    Sets the value of {@link #cfg-foo}.

Don't concatenate prettify lib with rest of JS/CSS.
This way the source code view and main app can easily share the prettify files.

I thought I had it fixed, but apparently not.
Now hopefully it's working.

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.