Revert the smart-select-ordering introduced in 36fd7f07

Revert the smart-select-ordering introduced in 36fd7f07

While on its surface an awesome idea, it proced to be problematic:
users of ->cursor and ->as_query expected that the result will have the same
column-order as what they put in the arguments. Also users abuse +select as
there's no tomorrow, which yielded interesting bugs. The current (and I hope
final) behavior is:

At the end of a chain, the resulting SQL will contain:

- a merger of all columns and then all +columns attributes in the
  declared order. If columns is declared as a multiselect hashref
  i.e. { as1 => sel1, as2 => sel2 }, then the selectors for this
  segment are ordered alphabetically. De-duplication is also always
  performed on columns arguments - only the first set of identical
  select/as pairs is preserved

- a merger of all select/as pairs, strict order, no deduplication

- a merger of +select/+as pairs, same rules as above

As a result of this prefetch on un-balanced resultsets now properly throws
an exception