Add generated Visual Studio project files to .gitignore

https://bugzilla.gnome.org/show_bug.cgi?id=699531
Add generated tarballs to .gitignore

https://bugzilla.gnome.org/show_bug.cgi?id=699531
build: make it clear generated documentation goes in $(builddir)

https://bugzilla.gnome.org/show_bug.cgi?id=699532
build: silence "make[5]: unlink: Regress-1.0-Python: Is a directory"

https://bugzilla.gnome.org/show_bug.cgi?id=699532
build: use diff -r when testing generated docs

https://bugzilla.gnome.org/show_bug.cgi?id=699532
giscanner: make _pass_read_annotations2() more readable

_apply_annotations2_function() is only ever called by
_pass_read_annotations2() so there's no need to go and
hide what's being done behind an extra method call.

Also change the 'if not something; return' into a more
readable 'if something: do something'...

https://bugzilla.gnome.org/show_bug.cgi?id=697622
giscanner: emit 'incorrect number of parameters in comment block' warning

instead of silently ignoring parameter names on signals when the
number of parameters doesn't match our expectations.

https://bugzilla.gnome.org/show_bug.cgi?id=697623
giscanner: Define source and header filename extensions only once

Enables us to to use a more effecient list membership test
instead of testing the end of some string multiple times.

https://bugzilla.gnome.org/show_bug.cgi?id=699533
giscanner: small cpp_args cleanup

No need for two variables...

https://bugzilla.gnome.org/show_bug.cgi?id=699533
giscanner: simplify the MainTransformer().transform() method

The ast.Namespace.names instance attribute is an OrderedDict
which itself is a specialised dict() subclass. There are any
number of ways to test if a dict() is empty or not. Creating
a copy of it's keys by iterating over them just to count the
number of items in the copy is not the most elegant way though.

https://bugzilla.gnome.org/show_bug.cgi?id=699533
giscanner: remove unneeded encode('utf-8').decode('utf-8') roundtrip

line is a unicode() instance, xml.sax.saxutils.escape() does
nothing more than call a couple of replace() methods on said
unicode() instance so it makes little sense to encode line
into a str() and decode the escaped result back into a unicode().

https://bugzilla.gnome.org/show_bug.cgi?id=699533
tests: Update misc/pep8.py to 1.4.5

Version in our tree is a wee bit outdated. For example,
later work will introduce an utf8 encoded python source
file which our old pep8.py does not yet understand (yeah,
it really was *that* ancient)...

Updated from:
https://raw.github.com/jcrocholl/pep8/1.4.5/pep8.py

Takes 552c1f1525e37a30376790151c1ba437776682c5,
f941537d1c0a40f0906490ed160db6c79af572d3,
5a4afe2a77d0ff7d9fea13dd93c3304a6ca993de and
a17f157e19bd6792c00321c8020dca5e5a281f45 into account...

https://bugzilla.gnome.org/show_bug.cgi?id=699535
giscanner: move odict.OrderedDict into a collections package

because we'll add more related code to collections later on

https://bugzilla.gnome.org/show_bug.cgi?id=699536
scanner: fix GTK-Doc comment block parsing

- GTK-Doc and current g-ir-scanner do not allow tags to be written before the
  comment block description but old version of g-ir-scanner parsed that just
  file. Fix this regression, but emit when tags are encountered at the wrong
  location. #674658

- During this analysis, a secondary bug report was filed with the GTK-Doc
  project because it was found that the same malformed tags did not result
  in the expected html output.

  After discussing this with the GTK-Doc maintainers, we learned
  that our g-i specific top level tags should never have existed
  in the first place. The prefered notation for annotations that
  apply to the identifier should be written on the identifier line,
  for example like what we already do with (skip).

  As a result, this patch deprecates g-i specific top level tags and
  implements them as annotations on the identifier instead and at
  the same time adds support for malformed comment blocks still
  using g-i specific top level tags.

  This means that all annotated code "out there" will continue to work
  just fine with this version of g-i, but when a developer decides to
  fix deprecation warnings in his/her comment blocks, the dependency
  on g-i needs to be raised to a version that contains at least this
  patch. #676133

- I previously (and foolishly) removed parentheses matching with
  a regex, which off course is not possible when there are multiple
  nested levels of parens (which we will now see more with annotations
  on the identifier, for example with the type annotation). Remove
  the "annotation parens matching" regexes again and add in more
  warnings on unbalanced/unexpected parentheses. #688897

https://bugzilla.gnome.org/show_bug.cgi?id=674658
https://bugzilla.gnome.org/show_bug.cgi?id=676133
https://bugzilla.gnome.org/show_bug.cgi?id=688897
tests: validate GTK-Doc test files

This is more of a handy developer tool than something
that is always expected to be executed as part of the
test suite, so we don't add a hard dependency on xmllint.

https://bugzilla.gnome.org/show_bug.cgi?id=688897
Add a tool fixing GTK-Doc comment blocks in .c and .h files

Just a standalone script for now, should probably eventually
go into g-ir-doctool or g-ir-annotation-tool...
docs: document some annotationparser.py hacking hints

https://bugzilla.gnome.org/show_bug.cgi?id=688897
Add giscanner package documentation

Using Sphinx [1] markup for now. We eventually might want
to add GTK-Doc support for python and dogfood g-ir-doctool
on this package.

[1] De facto standard Python documentaton tool: http://sphinx-doc.org

https://bugzilla.gnome.org/show_bug.cgi?id=688897
[WIP] docs: improve layout
!!! for testing only !!!