Modernize code action provider

[winstliu]

Easiest to review if you look at it per-commit, though there aren't too many changes overall so you could look at the overall diff too.

While investigating a pet peeve of mine in the VS Code C# experience (see below), I discovered that the CodeActionProvider class is using a legacy function signature for provideCodeActions. The new signature allows for returning CodeActions rather than Commands and also provides a more straightforward way to differentiate between Selections and Ranges.

Benefits:

• CodeActions enable the extension to return richer information about the underlying command which can then be reflected in the UI.
• The Range | Selection type means there's no longer a need to manually query editor state to determine whether there's an active selection.

Things seem to be behaving the same through a quick test I did with a file that had a diagnostic on ReferenceEquals(null, obj).

• No selection, active file: Displays the "Prefer 'is null'" quick fix, along with some code actions for wrapping arguments
• Selection on the first "e", active file: Only displays the "Prefer 'is null'" quick fix
• No selection, inactive file: Same as the active file scenario
• Selection on the first "e", inactive file: Same as the active file scenario

Note that the behavior I observed is different from what's documented in the VS Code API ("[range] will always be a selection if there is a currently active editor"), so it might be good to double-check me on that one.

I've also taken this opportunity to constify everything, because it seemed like pretty low-hanging fruit.

---

The pet peeve is that quick fixes aren't displayed in this tooltip right here which misleadingly makes you believe that there's no quick fix support:

I've figured out that passing kind: CodeActionKind.QuickFix to each CodeAction will cause them to show up in that tooltip. But to do that, CodeActions have to be returned in the first place ;).

[JoeRobich]

Thanks @50Wliu!