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