Rationalize versions used by the Project Query API implementation

## Summary

The Project Query API versions data so that it knows when something has changed and can automatically re-run queries. When using the project properties UI we always report the current version of the `ConfiguredProject` we're currently looking at, even though there is no guarantee that the property in question is related to that version. Similarly, when using the Launch Profiles UI we always report the version of the launch settings, even if a displayed property is ultimately stored in the project or .user file (in which case it is tied to the version of the `UnconfiguredProject` or `ConfiguredProject`.

This mostly works though it is technically incorrect, may lead to hard-to-diagnose bugs (like properties in the UI that don't update even when their underlying value changes), and (I think) points to a general lack of understanding of how to properly version data in CPS and the Project Query API.

On that last point, consider that the data in launchSettings.json is critical to the proper operation of the .NET project system but is not covered by CPS' concept of versions (which is mostly about tracking changes to MSBuild), so we version it ourselves. But perhaps we _shouldn't_ version it ourselves, and should instead increment the `UnconfiguredProject` version every time we produce a new set of launch settings.

Also consider that in VB scenarios Application.xaml and the .myapp file are exposed to the Project Query API, but the values aren't versioned at all. Among other things, this means that manual changes to these files will not automatically update the Project Properties UI. Again, it isn't clear to me if these should each have their own version, or if changes should be reflected in the `UnconfiguredProject`-level version.

We should discuss this with the CPS team. Tying all of these to the `UnconfiguredProject` version may be simpler but is a rather "coarse" approach that will cause the version to update more frequently and may lead to churn in unrelated parts of the system. If we go with individual versions that are more directly tied to the underlying data source (the Application.xaml file, the .myapp file, etc.) then we need to come up with a way for our project query API implementation to get the relevant version information with out the hard-coded knowledge it currently has.