Unbreak giscanner on OpenBSD.

Commit 9a1e0c63c13f3567e75553d2d07dd914d5b81287 broke this as
os.name doesn't return 'OpenBSD', but 'posix'

https://bugzilla.gnome.org/show_bug.cgi?id=696765
girepository: Use g_atomic for refcounting

They could be freed in separate threads (e.g. language binding GC
thread).  But no particular reason to change other than noticing it
during code inspection for a different bug.

https://bugzilla.gnome.org/show_bug.cgi?id=688694
gimarshallingtests: Fix vfunc_return_enum type

Change mistaken return type of GIMarshallingTestsFlags to
GIMarshallingTestsEnum in vfunc_return_enum.

https://bugzilla.gnome.org/show_bug.cgi?id=637832
scannermodule: Fix a bad check

Spotted by Coverity
Optimize g_irepository_find_by_gtype

When g_irepository_find_by_gtype() doesn't succeed on a simple prefix
match (the current 'fastpass' mechanism), it ends up taking a
considerable amount of CPU time, traversing the contents of all typelibs.

I imagine that the reasons to have the exhaustive search fallback are
not as strong as they used to be. For example, the case mentioned
(Clutter including Cogl) no longer seems to be true.

Also, typelibs (as generated by g-ir-scanner) now provide
comma-separated C prefix info for cases when the typelib includes
introspection info for multiple prefixes. For example, the Sugar typelib
has a c_prefix string of Sugar,EggSM,Gsm,Acme. So I imagine there are
not many remaining justified cases where the exhaustive search is needed.

With that in mind, I found two ways to optimize this function:

1. Support comma-separated C prefixes

2. Don't bother with an exhaustive search if we did find a typelib
   claiming support for the prefix. For example, if we're looking for
   GdkDeviceManagerXI2 (currently non-introspectable) and we already found
   typelib files providing the 'Gdk' prefix that didn't offer this, lets
   not bother with the exhaustive search, we aren't going to find anything.
typelib: Only malloc once during string iteration

Just more efficient.
typelib: Fix logic error in previous commit
gitypelib: And another fix for empty strings
tests: Restore intentional mixed tab/space indentation

Removed by accident in 2df621c53cdffbc3c43c3745947ee859020c8338

https://bugzilla.gnome.org/show_bug.cgi?id=697612
tests: fix a too wide search/replace

Changed by accident in 2df621c53cdffbc3c43c3745947ee859020c8338

https://bugzilla.gnome.org/show_bug.cgi?id=697613
giscanner: fix string formatting tuples

During review Colin Walters mentioned:

"""
One thing I should probably explain is my habit of *always* passing a
tuple for %.  The reason is pretty simple...a long time ago I had an
error handler that did:  print "unexpected data: %s" % foo.  And I'd
changed the type of "foo" from a string to a tuple at some point.
But this obviously caused "print" to fail because it was expecting
multiple format strings.

Basically always using tuples is safer in case you change the type
of a variable to a tuple.
"""

This fixes violations of this rule introduced up until now.

https://bugzilla.gnome.org/show_bug.cgi?id=697614
giscanner: remove unused variables and imports

https://bugzilla.gnome.org/show_bug.cgi?id=697615
giscanner: prefer "except X as e" over "except X, e"

It's more readable and as an added bonus Python 3 compatible.

https://bugzilla.gnome.org/show_bug.cgi?id=697616
giscanner: don't shadow built-in 'type' symbol

use the documented __exit__ signature instead

https://bugzilla.gnome.org/show_bug.cgi?id=697619
giscanner: use SqlAlchemy's OrderedDict implementation

g-ir-scanner can be a bit on the slow side. While true we
now do a bit more work parsing GTK-Doc comment blocks and
more is still to come, one of the biggest hotspots besides
what's going on in _giscanner.SourceScanner() comes from
the OrderedDict implementations we have been using.

For example, time needed to build Gtk-3.0.gir on a relatively
slow machine using "python2 -m cProfile -o $prefix/bin/g-ir-scanner ...":

1) Our original DictMixin sublass:
     92,79867 seconds
2) Python's collections.OrderedDict class:
     88,65786 seconds
3) Larosa/Foord implementation from http://www.voidspace.org.uk/python/odict.html :
     71,64323 seconds
4) SqlAlchemy's implementation:
     66,12449 seconds

Looks like we have a clear winner with the SqlAclchemy
implementation, which comes in at around 20 seconds
without profiling on the same machine. Not bad.

https://bugzilla.gnome.org/show_bug.cgi?id=697620
giscanner: fix broken xml:whitespace attributes in .gir files

The XML specification clearly states it's xml:space
http://www.w3.org/TR/xml/#sec-white-space

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

https://bugzilla.gnome.org/show_bug.cgi?id=697621
giscanner: use mkstemp() instead of mktemp()

mktemp was deprecated in Python 2.3...

https://bugzilla.gnome.org/show_bug.cgi?id=697624
giscanner: only parse GTK-Doc comment blocks, ignore the rest

For example, GTK+ has over 15.000 comment blocks (/* ... */)
of which only about 5.000 are GTK-Doc comment blocks (/** ... */).

No need to store and parse those +-10.000 comment blocks
just to find out we don't care about them anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=697625
remove ./configure summary

${enable_tests} was removed in f5631640751b5a998b3616db78dd5dcd9ee62126
so there's nothing left to report about...

https://bugzilla.gnome.org/show_bug.cgi?id=697669