The Top limit emulation bundled with SQLA::Limit assumes that the limited resultset...

The Top limit emulation bundled with SQLA::Limit assumes that the limited resultset will be _always_ sorted. In order to fix this, I reimplemented _Top in SQLAHacks with a slight modification. Now the original order_by is passed to the outside of the nested select block, while order_up/down are calculated either based on the original order_by, or if one is not present an order by all PKs is attempted.
Since I do not have access to $rsrc in SQLA, I pass the list of PKs as an extra group_by hash entry. This appears to be rather safe, and besides we already pollute order_by with group_by and having (which seems to work rather well).
The only thing I am unsure about is the need for _gen_virtual_order(). Initially I was going to generate the pk list, only if we use the Top limit. Then it turned out there is no limit dialect before we connect, so I commented it out. Now all it does is check for a limit condition and returns the PK list. Is this necessary at all?