Merge | Pull in the rest of the interop files

[benrr101]

Description: This PR is pretty straightforward, it brings in the rest of the files used for "interop". This is the first stage of a series of PRs that I've been working on that migrate the interop class to an interop namespace. This is a prerequisite for a prerequisite for merging LocalDBAPI. It is not strictly required, but it will make my life easier for merging the LocalDBAPI, and ideally it is work that should be done eventually anyhow.

Keep in mind if #2927 goes through, much of this code can be deleted since it is no longer needed in net8 or above.

This PR only moves the files, it does not make any code changes.

Testing: Projects still build, so there is no issue.

[benrr101]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mdaigle]

Suggested change

	#if DEBUG && !NETFRAMEWORK && !NET8_0_OR_GREATER
	#if DEBUG && NET6_0

[mdaigle]

I think it communicates the intent a bit better, but up to you. We'll delete them soon anyway.

[benrr101]

My rationale for using !NET8_0_OR_GREATER is because covers all versions below net8. I know we only build net6 and net8, and I guess it would be silly for someone to pull down the source and try to build it for eg, net7, but this is a fairly benign way to cover more bases.

I think of it similar to how we could do string.IndexOf("foo") == -1 or we could do string.IndexOf("foo") < 0, and how the latter is generally thought to be safer.

[edwardneal]

This looks good to me.

On a more general note, it looks like we're moving away from the various NativeMethods, SafeNativeMethods and UnsafeNativeMethods classes? If so my PR #2828 removes the currently-unused PInvokes from these code files, so there's no need to bother migrating those. There are quite a few other PInvokes in those files which are only used within the SQLDebugging class (and associated debugging infrastructure) though. I'd suggest ignoring those too - SQLDebugging is only used when debugging a client application connected to a local SQL 2000 instance, and when this is no longer permitted I'm planning to submit a PR which will eliminate that functionality and remove these PInvokes anyway.