Code fixes that impact additional files of custom item types no longer work

*Repro Steps*

1. Open Roslyn.sln, and add a public API somewhere in the CodeAnalysis.csproj project that triggers the PublicAPI checker.
2. Ctrl+.. Observe the suggestion from the code fix.
3. Apply it.

*Expected:* it works
*Actual:* it does nothing

Debugging on the Roslyn side of things, we are telling the RDT to save the item, but it bails because there is no hierarchy there:

```
if (((grfSave & RDTSAVEOPT_SaveAllButThis) == 0) && docCookie)
{
// cant save a doc anything w/o a hierarchy
if (NULL == info.spHier)
return NOERROR;
```

Roslyn, when it opened the invisible editor, passes null for [RegisterInvisibleEditor](https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.shell.interop.ivsinvisibleeditormanager.registerinvisibleeditor.aspx), which is documented that in this case it'll use whatever project "claims" the file. But if you look into the solution explorer, you'll see that PublicAPI.*.txt files aren't listed, and whatever data source drives that decision is also saying the project doesn't own the file for the purposes of the invisible editor. If you edit the project to change the item type to AdditionalFiles instead of PublicAPI, they now appear and code actions apply just fine.

The old project system was (to a fault) aggressive in counting unknown item group types as something to be "included" in the project; it seems the new project system is changing that behavior. The additional files with the PublicAPI item type do work otherwise in the IDE, as we [do tell the compiler to consume them](https://github.com/dotnet/roslyn/blob/781c5b0e7897dfa07644c3c760e5a24823baaaed/build/Targets/Settings.props#L21) and they're coming through with the design time build.

There is an interesting question of whether Roslyn passing `null` for the IVsProject property is "bad" (we might have one we can figure out), but it seems this is a regression in behavior at a few potential levels which might have other impacts -- any other callers are broken and the IsDocumentInAProject API is observing different behavior.