refactor: depend on numaflow to use native nats configuration struct

[KeranYang]

This change brings the following benefits:

1. Single source of truth on the NATS configuration struct. In the case of adding new features to the NATS source, to ensure NATS UDSource is in sync with the Numaflow platform NATS source, we now just need to update the dependency version of Numaflow instead of manually copying new attributes.
2. Auto-generated guide on each of the NATS configurations. We now use the native Numaflow guide API reference to show users how to specify a NATS UDSource configuration.
3. Ease to integrate with the current user-friendly numaflow NATS spec. On the Numaflow platform side, the controller can just parse the native NatsSource obj to JSON format and mount it to volume. NATS UDSource has no problem interpreting the JSON, saving one type translation.

Not so good:

One can argue that this brings in a circular dependency where NATS UDSource depends on Numaflow platform code while Numaflow depends on the NATS UDSource to run its built-in NATS source. However, the second dependency is simply a dependency on the image instead of a code dependency so it should be fine.

[vigith]

this doesn't seem right. what if you were writing the source in python? 😄

[KeranYang]

+1. Do you think if we move &v1alpha1.NatsSource from numaflow to this repo and let numaflow depends on this repo, it will be a better approach? As UDSource OWNS the definition of configurations and platform has minimal knowledge of it.