Fixes #205
Depends on #208
Based on #208

Extends the previous Ingress policy with an Egress policy. This prevents Cryostat's Pods from opening network connections to unexpected destinations. This primarily prevents things like:

1. Administrator installs Cryostat with target namespaces A, B
2. User defines Custom Target in namespace C

or

1. Administrator installs Cryostat with target namespaces A, B
2. User defines Custom Target on the open internet

or

1. Administrator installs Cryostat with target namespaces A, B
2. Misconfigured or malicious discovery plugin registers itself and publishes a target with a callback URI in namespace C, or on the open internet

As mentioned in #208, this is an additional layer and stronger enforcement of the ideas in cryostatio/cryostat-agent#242 and cryostatio/cryostat#323 . If enabled, it also would solve the problem underlying cryostatio/cryostat#685 , though it would be even better to also solve that directly in Cryostat.

Currently, the egress policy seems to cause connections between Cryostat and its database to fail when deploying to OpenShift (crc or otherwise). I was able to test it successfully in kind v0.25.0.

1. kind create cluster
2. kubectl create namespace test
3. kubectl create namespace apps1, then used the Operator's Makefile: make sample_app. Then kubectl edit svc quarkus-test -n apps1 and renamed the 9097 port to simply jmx so that it would not be auto-discovered.
4. kubectl create namespace apps2, then spun up another sample app instance the same as above.
5. kubectl ns test, then spun up yet another sample app instance but left this one with the jfr-jmx port name.
6. helm install --set core.discovery.kubernetes.namespaces="{test,apps1}" --set networkPolicy.egress.enabled=true cryostat ./charts/cryostat and follow the post-installation steps for port-forwarding
7. Once the deployment is ready and port forwarding is active, open the URL to visit the Cryostat UI. Everything should be working as normal and the quarkus-test target in test (installation namespace) should be discovered and usable as usual. The quarkus-tests in apps1 and apps2 should not be discovered.
8. Go to the Topology > Create Custom Target view.
9. Check that localhost:0 custom target can be tested for connectivity. It should succeed.
10. Check that quarkus-test:9097 custom target connectivity test fails quickly. The UI does not properly reflect it at the moment, but the Cryostat Pod logs should show that it is refusing to define this target because it has already been discovered.
11. Check that quarkus-test.test:9097 fails. This is the same as the previous step, just explicitly specifying the namespace instead of allowing it to be implicit.
12. Check that quarkus-test.apps1:9097 succeeds. This is the sample app in apps1 with the renamed port, so it is in a target namespace but not auto-discovered. Therefore, it should be possible to define this custom target.
13. Check that quarkus-test.apps2:9097 times out and fails. This is a sample app in apps2, which is not a target namespace, therefore the cluster should deny Cryostat's connection attempt to this application's service.

To test in OpenShift, simply install with --set networkPolicy.egress.enabled=false (or leave it unset, as false is the default). This should result in the same usual behaviour since the new policy should not be created.

Testing on minikube should result in nothing really happening differently, as the default minikube network provider does not support NetworkPolicy objects. They will still be created and kubectl describe networkpolicy will explain what they are intended to do, but no actual ingress/egress restrictions will occur.