Opt-out from reusing SQL Server transport's connection

[SzymonPobiega]

Adds DoNotUseSqlServerTransportConnection to the SQL Server dialect settings and moves the code responsible for adapting the transport connection to the dialects.

Fixes #144

[DavidBoike]

I was thinking how weird this is going to look to someone who isn't also using the SQL Transport. The comment here needs to tell the user why this would be necessary, and the answer is only if you were using a different connection string between SQL Transport and SQL Persistence, right?

So that got me thinking - can't we just look at the connection strings and enlist only if they match?

[SzymonPobiega]

@DavidBoike that used to be an option with NHibernate but since SQL persistence uses Func<DbConnection> it would mean that for each message we need to create the persistence connection using the factory and check if connection string's match.

Alternatively we can assume that the connection factory always returns connection with the same connection string and check only once but I am not sure if we can make such an assumption.

[DavidBoike]

In that case, we also can't detect when they have it misconfigured and throw an appropriate exception, because we don't even try creating a connection until we've determined we can't enlist, right?

I'm not sure I like that very much. I wouldn't want to wait around for an "invalid object name" exception with no further clue to what's really going on.

[SzymonPobiega]

How about trying to create the connection on strartup to capture the connection string there? We do that in SQL transport if user provides a func:

https://github.com/Particular/NServiceBus.SqlServer/blob/develop/src/NServiceBus.SqlServer/SqlServerTransport.cs#L64

[DavidBoike]

@SzymonPobiega I like the connection string capture on startup idea.

[SzymonPobiega]

@Particular/sqlpersistence-maintainers ping?