Content Type layer rule behaves unexpectedly on pages where no content is displayed with "Detail" display type

[rwawr]

Describe the bug

If a page does not contain any content items rendered with the "Detail" display type, all Content Type layer rules will evaluate to false. I would expect some Content Type rules to evaluate to true in this case, for example "Content type does not equal "MadeUpContentType"".

To Reproduce

Steps to reproduce the behavior:

1. Cook a fresh site with "Agency" recipe

2. Enable Search and Lucene features.

3. Add a search index
   

4. Add a new layer with a single Content Type rule configured with "Does not equal" as the operator and "MadeUpContentType" as the value.
   

5. Add a search widget to the Footer zone and configure it to use the search index and layer added previously.
   

6. On the front end of the site, search for anything

7. Notice that the search widget does not appear in the footer

Expected behavior

I would expect the search widget to still be rendered in this case because there are no content items of type "MadeUpContentType" rendered on the search results page.

In ContentTypeConditionEvaluatorDriver.EvaluateAsync, it seems like operatorComparer.Compare should be called with a blank value in the event that the _contentTypes hash set is empty. This would cause operators like "Does not equal", "Does not start with", "Does not end with", and "Does not contain" to return true, which seems reasonable, whild "Equals", "Starts with", "Ends with", and "Contains" will still evaluate to false, as they do currently.

[rwawr]

Added PR #15602 to address this. I tried to address the issue in my project by unregistering and overriding ContentTypeConditionEvaluatorDriver, but that won't work the way I want because of how conditions are added in the Orchard.Rules Startup class. The AddCondition extension method on IServiceCollection configures ConditionOptions by calling ConditionOptions.AddCondition, and there's no way to remove a condition or change the evaluator associated with it once that's done, since the _evaluators dictionary in ConditionOptions is private. So once a particular condition/evaluator combination is added, there's no way to override the evaluator for that condition. To work around this in my own code, I would need to add a new condition and everything that goes along with that in addition to the nearly identical evaluator class.