Let a SQL project point at a deployment contributor by path, and release the DLL lock outside build/publish

**Is your feature request related to a problem? Please describe.**

Yes. A deployment contributor is developed alongside the SQL projects it acts on, but the only way to
make a Visual Studio publish use one is to install it into the shared, machine-wide DAC Extensions
folder:

```
\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\Extensions\
```

That folder lives under `%ProgramFiles%`, so every rebuild of the contributor needs an elevated copy
before the change can be exercised from the IDE.

Every other consumer of the same contributor already avoids the folder. SqlPackage accepts
`/p:AdditionalDeploymentContributorPaths`, so our CI points at the contributor's build output
directory and never touches a machine-wide location. Only the IDE publish path cannot.

**Describe the solution you'd like**

Let a `.sqlproj`, and/or a `.publish.xml` profile, declare where deployment contributors live, so a
project can point at a sibling project's build output:

```xml

$(DeploymentContributorPaths);..\MyContributor\bin\$(Configuration)\net472

```

DacFx already has the concept - `DacDeployOptions.AdditionalDeploymentContributorPaths` - and
SqlPackage already surfaces it. The ask is to plumb that same option through the project system and
the Visual Studio publish path, so a value that works from the command line also works from the IDE.

**Describe alternatives you've considered**

- **An elevated copy script**, which is what we do today: it copies the contributor's build output into
the DAC Extensions folder with retry and read-only clearing, plus a `handle64` probe to name the
process holding the file when a copy fails. It works, and it is entirely mechanism that would not
need to exist if a project could name a path.
- **Symlinking the Extensions entries at the build output**, so a rebuild is live with no copy. It
removes the elevation after a one-time setup, but pins the machine to a single clone and
configuration - awkward alongside a second worktree - and leaves dangling links after a `clean` that
SSDT then fails to load rather than skipping.
- **`/p:AdditionalDeploymentContributorPaths` via SqlPackage**, which is the mechanism we want and
works well for CI. It is not reachable from a Visual Studio publish.
- **Co-locating the contributor into the SqlPackage folder**, which we do for offline
dacpac-to-dacpac script generation. Also command-line only, and no help to the IDE.

**Additional context**

We carry this as a commented-out property in our own build, because we went looking for it and found
it unavailable:

```xml

```

**Relationship to #341**, stated plainly rather than buried: #341 asks for the internal
`DeploymentContributorPaths` to become "configurable as a task property mapped from the SQL project,
rather than relying on a static default value". That is the same property and the same complaint. The
difference is the stage - #341 is a contributor failing to load during **build** of an SDK-style
project, this is **publish** from the IDE. If they are better served as one item, folding this into
#341 is welcome; it is raised separately only because the publish path is not covered there.

There is a second half to this developer loop that is not DacFx's to fix: Visual Studio holds an open
handle on the contributor DLL for as long as a SQL project is loaded, so the elevated copy also
requires closing the IDE. That is filed with Visual Studio separately. Resolving the path ask here
would make it much less painful even if the lock never changes, because the copy would no longer be
needed at all.

---

Trace the Visual Studio publish path and compare it with SqlPackage's AdditionalDeploymentContributorPaths and DacDeployOptions.AdditionalDeploymentContributorPaths. The change is complete when a .sqlproj or .publish.xml value reaches IDE publishing and contributors can load from a project build-output path without copying into the machine-wide DAC Extensions folder.

Written by the indexing model from the issue text.