Ssdt bugfixes

[JordanMarr]

Proposed Changes

• Creates a more comprehensive splitFullName function as a regex (with added unit tests)
• First attempt to fix SSDT stored procs so that they always return a SprocResult instead of returning unit per request in #706.

Types of changes

What types of changes does your code introduce to SQLProvider? Put an x in the boxes that apply

• [x] Bugfix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• [ ] Build and tests pass locally
• [x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• [ ] I have added necessary documentation (if appropriate)

Further comments

Please let me know if the stored proc change works for your use case.

[Thorium]

For some reason after this PR the test project build fails as: "System.Exception: NUnit: cannot run tests (the assembly list is empty)."

[JordanMarr]

For some reason after this PR the test project build fails as: "System.Exception: NUnit: cannot run tests (the assembly list is empty)."

Is that coming from the MsSqlSsdt.Tests project? EDIT: never mind, I'm looking at the error log now...

[JordanMarr]

For some reason after this PR the test project build fails as: "System.Exception: NUnit: cannot run tests (the assembly list is empty)."

I did make a few small changes to my test project, but it looks like my tests are not being executed by the CI build since they are not included in SQLProvider.Tests.sln.
Outside of that, all my changes were isolated to Providers.MsSqlServer.Ssdt.fs, so it's not clear how that could cause a problem with the main tests.

[Thorium]

The test runner picks assemblies by "tests/**/bin/Release/*Tests*.dll" and that seems to hit the MsSqlSsdt.Tests. Should these tests be run on build or not?

[Thorium]

Ok, it seems that the build doesn't find the unit tests anymore. This cannot be issue of this PR, it has to be some kind of update from internet, either to VisualStudio, Fake or Paket.

The test passed when I ran them from VisualStudio manually. So I released this to NuGet as SQLProvider version 1.1.100

I'm not too keen to spending time fixing the environment as I think we should move towards releasing from the net-standard branch, as SQLProvider 1.2.

[JordanMarr]

I put the SSDT unit test project inside its own .sln so that I could reference the SSDT .sqlproj in it as well. I never added the new sln to the build, so I'm pretty sure the tests are not run during the CI build. I'll add it on the next round of changes.