## Description

SourceLink is needed to ensure that our NuGet packages have matching source information when symbols are resolved. So we have an `EnableSourceLink` property which tells some of our projects to add source link, and we enable that when doing CI/PR/official builds by setting the property to true when we call msbuild in our pipelines.

This PR makes it so that instead of having to pass that property, the projects themselves automatically build with source link when they need to.

### Type of Change
- New feature (non-breaking change which adds functionality)

### Why
This makes it so that local builds of RNW are closer to the the same nuget restore behavior / packages.lock.json file as when they're built in pipelines.

This is part is working toward resolving #12004 and this functionality was extracted from PR #13634.

### What
Instead of requiring us to call msbuild with `/p:EnableSourceLink=true` for every solution (or relying on setting it in `ExperimentalFeatures.props`) we now detect when our library projects are being built within the repo (detecting the `src-win` folder which isn't present in the NPM publish) and enable source link then.

## Screenshots
N/A

## Testing
N/A

## Changelog
Should this change be included in the release notes: _yes_

Automatically set EnableSourceLink for in-repo builds only

## Description

Projects "built for Fabric" depend on the `Microsoft.WindowsAppSDK`, while projects "built for Paper" rely on `Microsoft.UI.Xaml`, both of which are mutually exclusive. This leads to a lot of PRs with a spurious flip-flopping of the contents of nuget package lock files, depending on which flavor the author happened to build against.

This PR enables a new separate fabric lock file for projects and also updates all of the lock files.

### Type of Change
- New feature (non-breaking change which adds functionality)

### Why
This makes it so that local builds of RNW are closer to the the same nuget restore behavior / packages.lock.json file as when they're built in pipelines, namely to reduce the number of spurious lock file changes we see in PRs.

This is part is working toward resolving #12004 and this functionality was extracted from PR #13634.

### What
For projects building within our repo that can be built as either Paper or Fabric variants, we now maintain a separate "fabric" nuget lock file: `packages.fabric.lock.json` alongside the normal `packages.lock.json` file (which can be either "paper" or "fabric" depending on what the project normally builds with).

## Screenshots
N/A

## Testing
N/A

## Changelog
Should this change be included in the release notes: _yes_

Create separate NuGet restore lock files for Fabric builds