Bumps [Microsoft.PowerShell.SDK](https://github.com/PowerShell/PowerShell) from 7.3.1 to 7.3.2.
- [Release notes](https://github.com/PowerShell/PowerShell/releases)
- [Commits](PowerShell/PowerShell@v7.3.1...v7.3.2)

---
updated-dependencies:
- dependency-name: Microsoft.PowerShell.SDK
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Since `FindReferencesOfSymbol` is already used.

This required using a `ScriptFile` for the associated test in
`AstOperationsTests`. The coupling of the visitor to the file seems fine
since that's the _point_ of this improvement: a cached sets of
references for each file. We also have to carefully sort our list of
symbol references for things that expect them in order.

…romScriptRegion`

At least I'm pretty sure these were unnecessary duplicates.

Since the client doesn't actually care which order we return the
references in, we should skip unnecessarily sorting. It appears to apply
its own sorting to the results regardless of their order, and the
specification doesn't say it needs to be sorted.

Also adjust two tests to account for the definitions being in the
reference lists.

This lets us (nearly) replace `FindSymbolsInDocument` by using the references
(symbols) from the `ScriptFile`.

We were missing the distinction between properties and enum members,
as well as DSC configuration.

`StartOffset` is always 0, sort by `Range.Start` instead.

While we're debugging it.

And also prepare `SymbolReference` for eventual support of `DocumentSymbol`.

This has been unused and sometimes broken,
it doesn't actually power any useful features.

…isitor`

`SymbolsService` is now nullable too.

It's so sad we can't use `IAsyncEnumerable`.

By starting at the start of `NameRegion`.

Co-authored-by: Frode Flaten <[email protected]>

And guard from null exception in definition handler.

Name was wrong.

To actually be an inclusive check of the given point being
between the two boundary points.

Space between name and subsequent parenthesis.

Let it be known that Patrick bets $500 that no one notices this.
And to be fair, searching the whole workspace now works great.

And delete "find details" for non-commands (as they all get their
display strings set on creation now).

The visitor exists but it's not called, probably a module-import issue.

Co-authored-by: Patrick Meinecke <[email protected]>

So that we rely on the dictionary to sort our symbols into the equivalent
types instead of having to perform a filter.

I think there's a cleaner way to do this, but this works.

Against the full name and not just the identifier, since it's
what's displayed in the search menu.

Now you can search methods by their parameters' names.

Should have been just `IndexOf`, and also use `+` instead
of `string.Concat()` for simplicity and speed.