Use AstNode class.

Builtin tags can now define @ext_define_pattern - which causes
the #parse_ext_define method to be invoked when such an item is
encountered within Ext.define config.

Instead of using the raw AST node values.

For start for the simpler things like extend, singleton, mixins, uses, ...

Allows iterating over object expression properties.
Also using it in Ast#detect_ext_define.

This eliminates much of the ext_* methods from Ast class.

Eliminating some Ast class methods that are now taken care of by AstNode class.

This way it doesn't have to be initialized every time Ast class
is invoked. Also one less options object to be passed around.

The purpose of the base class is to clearly separate out methods that
can be called from @tag implementations.

All builtin tags are now implemented as tag classes.

Extract parts of the parsing routine into separate methods so
that the #at_inheritdoc method works at a more higher level.

The use of #skip_white must have been a mistake.

Instead call it at the top level method, ensuring it will be
called always after parsing any tag.

Just using the add_tag method like previously, but the actual
parsing of the @tag is performed in parse_at_tag method before
control flow reaches the method for parsing the concrete tag.

The code should be now both cleaner and faster (we're no more calling
look(/regex/) repeatedly to decide which at_tag method to call).

Remove bunch of duplication by parsing similar tags with a more
generic functions.

Also avoid repeating regexes by not testing for the exact tagname
any more after the first initial check.  The new helper method
parse_tag_as() replaces in lots of places two lines of code with
just one.

The offical 0.11.0 seems to have some problems compiling.
So stick with the latest beta instead.

For windows we also use the 0.11.0beta1, so that's ceartanly
a better option than defining 0.10.1 as dependency.

Github no more provides hosting for downloads. So switching over
to SourceForge.net.

Generate full paths for images in guides

Suppose we're using JSDuck to generate guides from the following directory
structure:

somedir/
  guides.json
  guides/
    getting_started/
      README.md
      some-image.png
    nested/
      first_guide/
        README.md
        one.png
      second_guide/
        README.md
        one.png

In JSDuck's generated HTML, image tags in the Getting Started guide will point
to the correct path relative to the page (e.g.
'guides/guide_getting_started/some-image.png'). However, the nested guides will
specify the wrong paths to images: JSDuck will write
'guides/first_guide/one.png' instead of the correct
'guides/guide_nested_first_guide/one.png'.

This patch fixes the issue by generating the image's path based on the full
name of the guide, instead of using 'File.basename' to incorrectly crop the
path.