Move setup scripts into separate folders

[Charles-Gagnon]

We've started seeing test failures like this on Linux

Failed Microsoft.Azure.WebJobs.Extensions.Sql.Tests.Integration.SqlInputBindingIntegrationTests.GetProductsTest(n: 0, cost: 100) [1 ms]
Error Message:
Microsoft.Data.SqlClient.SqlException : Invalid object name 'Products'.
Stack Trace:
at Microsoft.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at Microsoft.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at Microsoft.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at Microsoft.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at Microsoft.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean isAsync, Int32 timeout, Boolean asyncWrite)
at Microsoft.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, Boolean sendToPipe, Int32 timeout, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry, String methodName)
at Microsoft.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at Microsoft.Azure.WebJobs.Extensions.Sql.Tests.Common.TestUtils.ExecuteNonQuery(IDbConnection connection, String commandText, Predicate`1 catchException) in /home/vsts/work/1/s/test/Common/TestUtils.cs:line 63
at Microsoft.Azure.WebJobs.Extensions.Sql.Tests.Integration.IntegrationTestBase.ExecuteNonQuery(String commandText) in /home/vsts/work/1/s/test/Integration/IntegrationTestBase.cs:line 266
at Microsoft.Azure.WebJobs.Extensions.Sql.Tests.Integration.IntegrationTestBase.SetupDatabase() in /home/vsts/work/1/s/test/Integration/IntegrationTestBase.cs:line 124

During the database setup it seems like the scripts are being ran out of order - so the "create view" script was being ran before the table it was over was actually created.

It isn't clear at all why this suddenly broke - but given that our setup is just globbing all the .sql files from the directory that isn't guaranteed to come back in a specific order so wasn't safe to begin with.

The simple fix for this is just to be more specific about the order we execute them in. As the comment in the setup mentions using something like a sqlproj would be even better from a consistency standpoint, but that's a bit more than is the worth the effort at this time.

(I also added a few debugging messages to help diagnose future problems)