APIExtractor as a first class tool, and as a backend for binding generators / using APIExtractor standalone

I'm overdue to open this issue, per previous IRC discussion with crmaurei
and kleint, I appreciate your help, and being available to discuss this!
I was also told people have asked similar things before.

Haskell does not have a good native GUI story. Bryan Gardiner is writing raw, non-
idiomatic bindings to Qt in Haskell ( http://khumba.net/projects/qtah/ ) using his C++
FFI generator ( http://khumba.net/projects/hoppy/ ).

Currently every foreign class, function, etc. definition is hand written, so the
coverage of the Qt API is quite low. An example specification for QPushButton can
be seen on the hoppy page, and a version of the documentation listing what
functions exist can be browsed at https://hackage.haskell.org/package/qtah-qt5-0.5.1

My understanding is the following:

PySide/Shiboken contains a component called APIExtractor, which leverages
CLang/LLVM to inspect the Qt codebase and acquire information necessary for
binding generation.

However, currently the tool is only exposed through a static library used by
Shiboken, and the information it extracts cannot be accessed in a standalone
manner.

Furthermore, I see no reason why the information could not be dumped to a
language-agnostic database for every Qt release+, allowing the information to be
used without needing to run the tool at all. I hypothesize this will promote
binding generation to any language.

+(I would /personally/ prefer this not to be XML)

Thus, I propose:

• give APIExtractor a CLI frontend, with documentation
• compile APIExtractor as a shared library, and document the code
• release a pre-generated language-agnostic information database with every qt
  version

Per the previous discussions, I'm told the Qt documentation generator also uses a
somewhat similar approach (for getting function signatures into the
documentation?) - this is more evidence that benefits can be had from a standalone
tool.

There are probably additional applications here. I don't know if the KDAB GammaRay
people would have use for such a database?

(Somewhat tangentially, kleint mentioned the attachment of
https://bugreports.qt.io/browse/PYSIDE-323 as related / more lightweight)