improve bpfman-operator application conditions so that they follow established conventions

Conditions transitions from:
```
conditions:
- lastTransitionTime: "2025-10-23T12:24:02Z"
message: Waiting for Bpf Application Object to be reconciled on all nodes
reason: Pending
status: "True"
type: Pending
```

To:
```
status:
conditions:
- lastTransitionTime: "2025-10-23T12:24:22Z"
message: BPF application configuration successfully applied on all nodes
reason: Success
status: "True"
type: Success
```

The `Pending` condition is removed. But IMO that's not how it should work in k8s.

https://kubebuilder.io/reference/good-practices#why-you-should-adopt-status-conditions
```
We recommend you manage your solutions using Status Conditionals following the [K8s Api conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md) because:

Standardization: Conditions provide a standardized way to represent the state of an Operator’s custom resources, making it easier for users and tools to understand and interpret the resource’s status.
Readability: Conditions can clearly express complex states by using a combination of multiple conditions, making it easier for users to understand the current state and progress of the resource.
Extensibility: As new features or states are added to your Operator, conditions can be easily extended to represent these new states without requiring significant changes to the existing API or structure.
Observability: Status conditions can be monitored and tracked by cluster administrators and external monitoring tools, enabling better visibility into the state of the custom resources managed by the Operator.
Compatibility: By adopting the common pattern of using conditions in Kubernetes APIs, Operator authors ensure their custom resources align with the broader ecosystem, which helps users to have a consistent experience when interacting with multiple Operators and resources in their clusters.
```

The conditions should IMO not be removed after they are no longer true, so Pending should remain as a condition forever. I'm not sure if it should transition from Unknown to True to False, or if it should stay True forever (in deployments, `Progressing` definitely stays `True` forever, but `Available` then switches to `True` and that's how one knows that the deployment is done via conditions.

However, https://superorbital.io/blog/status-and-conditions/ makes a good point:
```
When a Condition’s "True" status represents normal operations, it is referred to as a “positive-polarity” condition, whereas Conditions where "False" represents this state are “negative-polarity”. Standardize all your Conditions to use the same polarity to represent normal operations. This will help avoid confusion when scanning the conditions list and seeing a mix of "True" and "False" status values during normal conditions.
```

So I'd advocate for having Pending: True coexist with Success: True

See https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md
and https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties
```
Although they are not a consistent standard, the Ready and Succeeded condition types may be used by API designers for long-running and bounded-execution objects, respectively.
```

IMO, there should be a condition: `Pending` which transitions from `False` to `True` and the `Reason` should be more explicit, such as `WaitingForReconcile`. There should be another condition, `Succeeded` or `Ready` and the reason should be

By the way, note that conditions in the STATUS field can and should be tracked with something like:
// +kubebuilder:printcolumn:name="Available",type="string",JSONPath=".status.conditions[?(@.type=='Available')].status"

And not via the index [0] as we're currently doing