Fix default features control by top level manifest

[dg0yt]

For microsoft/vcpkg#35694 (comment):

Given that the app (aka top level) manifest defines the user's desired installation, should installing feature set no-default-features-3 really behave different from feature set no-default-features-1,no-default-features-3 with regard to the dependency on vcpkg-default-features-fail-require-other-feature?

... test manifest features: no-default-features, features = [no-default-features-1,no-default-features-3]
... (success)
... test manifest features: no-default-features, features = [no-default-features-3]
... (failure)

[dg0yt]

@BillyONeal and team, please have a look.

[dg0yt]

@JavierMatosD This is the demo where even the top-level manifest isn't honored. (I prefer to refer to app manifest.)
microsoft/vcpkg-docs#255

[dg0yt]

Fixing a test mismatch:

• In these tests, the default top level name is "toplevel-spec", but no dependencies passed to create_versioned_install_plan are using that name (before this change).
• In regular manifest mode operation, the top level spec is the app spec, i.e. it carries the name of the app, and all dependencies passed to create_versioned_install_plan are using that name.

The observed bug cannot be fixed and tested without aligning top level spec name and dependencies.
This PR does the change only in two cases.
But probably this should be aligned for all calls to create_versioned_install_plan which deal with (default) features.

[BillyONeal]

The top level manifest is allowed to have no name though, hmmm...

[dg0yt]

I can imagine why (overlap with registry), but:

• This adds to the problem of having two classes of manifests.
  (Known for default-features and for version constraints.)
• This adds to the problem of the tests mismatching actual manifest mode invocations.
  Unless "top-level" is the implicitly forced name - this might make sense for UX in error message, but then it needs to be protected from other uses.

[dg0yt]

And this PR makes no assumptions about the actual name of the top level manifest - it can be the empty string.

EDIT: But behavior changes for the dependencies of a port which has the same name as the app.

[dg0yt]

The top level manifest is allowed to have no name though, hmmm...

For clarification, this is what the tests use:

vcpkg-tool/src/vcpkg-test/dependencies.cpp

Lines 159 to 163 in 9c1e418

	static const PackageSpec& toplevel_spec()
	{
	static const PackageSpec ret("toplevel-spec", Test::X86_WINDOWS);
	return ret;
	}

[BillyONeal]

It is true that the case where this matters can only happen when there is a name, since you need to be able to form the dependencies block, which requires a "name". The issue is that the top level name is not required to exist, and this removes a lot of test coverage of that feature.

I think the minimum to proceed is to not remove that test coverage.

I think a separate feature where a vcpkg.json is able to depend on itself without specifying a name, like:

{
    "features": {
      "a": {
        "dependencies": [
            {
                "$comment": "No name at all means 'self'",
                "features": ["b"]
            }
        ]
      },
      "b":{}
    }
  }

or

{
    "features": {
      "a": {
        "dependencies": [
            {
                "self": true,
                "features": ["b"]
            }
        ]
      },
      "b":{}
    }
  }

or

{
    "features": {
      "a": {
        "feature-dependencies": ["b"]
      },
      "b":{}
    }
  }

would be nice, but I don't think that bike shed needs to be painted to land this.

[dg0yt]

Did the team give up on default-features?
You don't engage much in issues and discussion, you don't fix clear bugs quickly, and now you also turn off project defaults because "Default features are complicated to disable" (microsoft/vcpkg#36982 (comment)).

[Thomas1664]

Did the team give up on default-features? You don't engage much in issues and discussion, you don't fix clear bugs quickly, and now you also turn off project defaults because "Default features are complicated to disable" (microsoft/vcpkg#36982 (comment)).

@dg0yt Given that this is an issue that affects many users, I think this would be a great candidate for merging into open-vcpkg/vcpkg-tool?

[dg0yt]

What is needed for this PR to be merged?

[BillyONeal]

Thanks for the fix! Sorry it took so long for me/us to convince myself/ourselves that the handling of nameless manifests was correct