Convert GVFS.Native.Mac.xcworkspace into a .xcodeproj

From Phil in #1146 (see the PR for more discussion)

We should also include the new native notification .app in this new .xcodeproj.

Xcode Workspaces are very loose aggregations of Projects. (They are not as powerful as Visual Studio "Solutions" - those are closer to Xcode Projects.) The only thing you really can do with them is create super-project build Schemes. One of the main downsides is that they don't allow cross-references between projects - e.g. you can't have a Target in one project be a build dependency for a Target in another project if the only connection between those projects is that they're contained in the same workspace.
You can however nest projects - in this case, the outer project can depend on Targets from the inner project. This isn't exactly the same as having the Targets in the same project of course - project-wide properties aren't propagated to sub-project Targets, and the sub-project's Targets can't depend on the super-project's Targets.
Without looking at the merits of the different approaches for this specific case, my order of preference is normally:
Add new "projects" (apps, tools, libraries, etc.) as Targets to an existing Xcode Project.
If the new thing really doesn't fit with an existing Xcode Project but uses something from an existing Xcode Project, then nest the existing Project inside a new Project containing the new Target. The new Target can then e.g. link against libraries built by the existing Project.
If the new thing is only extremely loosely related to the existing Xcode Project, but you want to be able to build everything in one go from within Xcode, create a new, unrelated Project for the new thing, then nest both it and the existing Project inside a newly created umbrella project. The umbrella project contains an aggregate build Target which simply lists Targets from both sub-projects as dependencies.
I'm not aware of any scenario where you'd prefer a workspace over any of the above. I'm sure personal taste comes into this too - as I mentioned, Schemes can be created in workspaces, and you can get multiple unrelated targets to build by creating a combined Scheme for them. I just find Schemes too loose, on the whole, because they don't really compose.
GVFS.Native.Mac.xcworkspace could presumably be turned into an umbrella project instead of a workspace.

Start with GVFS.Native.Mac.xcworkspace and the referenced discussion in issue #1146; inspect how the current workspace groups projects and how the new native notification .app should be included. Confirm the replacement .xcodeproj builds the existing targets and includes that app, then verify the workspace is no longer required.