Roslyn: Allow public use of CodeActionWithNestedActions

[RyanCavanaugh]

Version Used: Current master

Steps to Reproduce:

1. Try to instantiate CodeActionWithNestedActions
2. Nope, internal
3. 😢

Expected Behavior: Should be able to create CodeActionWithNestedActions through either some other overload to Create or with new

Actual Behavior: Can't create "grouped" refactorings because there's no public way to create an instance of that class

/cc @CyrusNajmabadi

[Pilchie]

I'm okay with opening this up for 15.6. @CyrusNajmabadi @DustinCampbell @kuhlenh any objections?

[Pilchie]

@RyanCavanaugh PS - we take PRs 😉

[DustinCampbell]

No objections from me since I had to resort to reflection in OmniSharp to properly support code actions. Without exposing this, Roslyn API consumers and code fix authors are at a disadvantage.

[CyrusNajmabadi]

We shoudl def make this available. Though i think teh correct way to do this is to just allow CodeAction to have nested children (that's actually how the property is exposed). I dont' think there's a need for a distinct subtype.

Also, we have to decide how we want to expose the "can my children be flattened directly into the lightbulb if there aren't that many items?" flexibility that we currently have.

[CyrusNajmabadi]

Solution: Just give IVT to ryan. (note: not typescript. just ryan).

[DustinCampbell]

:smile:

[sharwell]

Prioritizing this on the grounds that IDE analyzers shall not have special privileges. We either need to expose this functionality, or remove uses of this functionality within dotnet/roslyn.

[CyrusNajmabadi]

It's less of an objection and more like: the API here is really ugly. We shouldn't expose CodeActionWithNestedActions. it should just be that any CodeACtion can have nested children :)

[sharwell]

I'm thinking a new overload of CodeAction.Create:

public static CodeAction Create(
    string title,
    ImmutableArray<CodeAction> nestedActions,
    bool isInlinable)

[CyrusNajmabadi]

I think that's reasonable.

[RyanCavanaugh]

🎉