Allow independent configuration of AcquisitionFrameRate for hardware triggering

[michaelarusso]

Allow independent configuration of AcquisitionFrameRate for hardware triggering

Problem:
When a camera operates with TriggerMode=On (using an external hardware trigger), forcing the camera's AcquisitionFrameRate to exactly match the negotiated GStreamer pipeline framerate capability causes frame drops and rate inconsistencies. This occurs because the clock of the external hardware trigger drifts relative to the Basler camera's internal clock, resulting in missed triggers when the strict timing window is violated.

Context:
In GenICam/Pylon, AcquisitionFrameRate is documented to act as an upper limit (throttling boundary) to prevent over-triggering, rather than a strict interval setting, especially when using external triggers. However, the plugin previously blacklisted these properties and unconditionally forced the camera's framerate to strictly mirror the GStreamer capability negotiated during caps resolution.

Solution:

1. Removed property blacklisting: AcquisitionFrameRateEnable, AcquisitionFrameRate, and AcquisitionFrameRateAbs have been removed from the propfilter_set in gstpylonfeaturewalker.cpp. This allows users to correctly expose and configure these parameters directly via GStreamer element properties (e.g., cam::AcquisitionFrameRateEnable=True) or via PFS.
2. Honoring user configuration: Modified the configuration logic in gst_pylon_set_configuration() to check if AcquisitionFrameRateEnable was previously enabled (either via a PFS config or element properties). If enabled, the plugin honors the pre-configured limit and skips overwriting it with the pipeline's arbitrary caps framerate.
3. Fallback to caps: If the user does not explicitly configure these parameters, the plugin preserves its original behavior: it enables the property and derives the camera framerate directly from the downstream GStreamer caps negotiation.