EgressRules has situations where strict ordering is a problem

### Problem

Mixing of ip\_block and hostname-based rules based on ordering forces the implementation to handle all of the evaluation in a single place, but this might not be possible/efficient: commonly IPs are known and evaluated at lower layers vs hostname, which is an L7 (e.g. HTTP) property.

Imagine we have an egress policy:

```
"egress_policy": {
"metadata": {"atespace": "default", "name": "default"},
"rules": [
{ # a range covering api.github.com
"ip_blocks": { "cidrs": ["140.82.112.0/20"] }
},
{
"hostnames": {
"patterns": ["api.github.com"],
"effects": { ... }
}
]
}
```

Currently, the rule evaluation order is:
```
// Rules are evaluated in order. The first matching rule authorizes the
// request, only that rule's effects are applied, and evaluation stops even if
// later rules would also match. A request is denied when no rule matches.
//
// +k8s:optional
// +k8s:maxItems=256
// +k8s:listType=atomic # rule order matters
repeated EgressRule rules = 2;
```

This suggests that the `hostname` rule will not be evaluated.