Lightspeed for frmQuery and other issues.

Hi Dave,

as announced I realized the virtual listview implementation in frmQuery;
the code became amazingly slim. Since there's no more data retrieval,
the retrieval time shrinks to precisely 0.00 microseconds which should
be sufficiently fast to justify omitting this value :-)

I left grid stuff #ifdef'ed in the source, but it can't work for now.
When this is reworked, I'd really appreciate if the interface of
ctlSQLResult isn't altered again (there shouldn't be a need to touch
frmQuery), and until a different solution is accepted the alternate
#define USE_LISTVIEW should remain.

At the same time, I noticed how reporting was added to pgAdmin, and was
quite horrified. The menu refactoring was done to avoid base class
cluttering, and now it is massively reinvented. Any adding to menu.h is
plain wrong for frmMain menu, any code adding in events.cpp (beyond
minor submenu handling, i.e. calling enableSubmenu) too, touching base
factory classes even more. All reporting stuff should be implemented in
frmReport, not in pgObject or so. Please do refactor it using factories.
BTW, I wonder why the reporting is creating HTML, not XML.

I added a scripting option, which will (for std. objects) call the query
tool with reengineered script as usually performed with the sticky bit
set. IMNSHO we can drop the option now, because both behaviours are now
available at the same time.
Scripting of SELECT, INSERT and UPDATE (typing the col names can be
boring) coming soon.

Regards,
Andreas