Refactor prepared insert_select support

This adds Dataset#insert_select_sql whereever #insert_select is
supported, and changes the prepared statement code to use that
instead of assuming returning is supported if insert_select is
supported.

This also adds integration tests for using insert_select with
bound variables and prepared statements.  Previously it was
tested indirectly via the prepared statement plugin support,
but it is better to also test support directly.

Additionally, this switches the adapters that implement
insert_select to all use with_sql_first to retrieve the row,
instead of either calling insert or manually trying to set
the SQL, which should be faster.

Remove the previous hack to the MSSQL adapter to get insert_select
to work.
Minor style changes to Dataset#output in shared mssql adapter
Emulate RETURNING on Microsoft SQL Server using OUTPUT, as long as only simple column references are used

If only simple column references are used, you can take the
RETURNING values and automatically qualify them with INSERTED
or DELETED depending on the query, and they pretty much work
directly with the OUTPUT clause.

If both RETURNING and OUTPUT are specified, give OUTPUT priority.
If the returning clause is already present, have insert_select
use it instead of creating a new OUTPUT clause.
Calling Dataset#returning when the Database does not support or emulate RETURNING now raises an Error
Add Dataset#unqualified_column_for helper method, returning unqualified version of possibly qualified column

This is a modified version of _returning_output_value from the
mssql adapter, but with better handling of corner cases.  I
plan to use it in future work, so it will be helpful to have in
core.
Make Model#save use insert_select if the dataset used for inserting already uses returning

Previously, if the model's dataset selected specific columns,
insert_select was not used.  This was because insert_select
used to automatically use RETURNING *, and if the dataset
did not SELECT *, using insert_select could change the columns
returned (e.g. turning a lazy loaded column into an eager loaded
column).

However, since insert_select now respects an existing
RETURNING clause, you can set the RETURNING clause appropriately,
so that insert_select wouldn't change the behavior, and then
it is beneficial to use as it reduces the number of queries.
Add insert_returning_select plugin, for setting up RETURNING for inserts for models selecting explicit columns

This takes away the insert performance hit when using the
column_select or lazy_attributes plugins.
Make bin/sequel add lib directory to front of $: instead of end

This fixes an issue where some code you run inside of bin/sequel
requires a gem that depends on sequel, in which case the gem
directory gets added before the lib directory.  Since the point
of this change to bin/sequel was to make make:

  bin/sequel

act like:

  ruby -I lib bin/sequel

The lib directory should go at the front of $:, since that is
what ruby -I does.
Use an expanded path when adding lib directory to $:

This fixes issues when changing the current directory.
Require sequel later in bin/sequel

This makes it so bin/sequel -h doesn't need to require sequel,
and errors executing bin/sequel are returned without requiring
sequel, speeding bin/sequel up.  Also, if requiring sequel raises
an error, it is returned on one line instead of displaying the
full backtrace by default (still respecting -t to get the full
backtrace).
Make bin/sequel give an error if using -C with any of -cdDmS
Make bin/sequel -v not exit if database/code string given

Previously, bin/sequel -v exited in all cases.  Now, it operates
more similarly to ruby -v, printing the version but continuing
if a database or code string is provided

I think it would be a good idea to extend this behavior so that
if code is piped in, it also executes it after printing the
version, but that is not currently ruby's behavior, so it shouldn't
be bin/sequel's either.
Unalias aliased tables in Dataset#insert

Some databases support aliased tables in UPDATE and DELETE, which
makes sense as they have WHERE clauses.  None that I could find
support aliasing the table in INSERT, so it should be safe to
unalias the table there.

This allows you to have a dataset with an aliased table and
insert, update, delete, and select using it, assuming your
database supports tables aliases in update and delete.
Make unaliased_identifier return input symbol if it does not contain an alias

Also, don't create symbols for the returned column value if
it does contain an alias, just use a SQL::QualifiedIdentifier
or SQL::Identifier with the string.