fix: Use server config for direct bindings

[JorTurFer]

Using direct bindings, the consumer shouldn't need to know about the already configured consumer in the server.
This PR overrides user given configuration (if given) with server received configuration in cases where a direct binding is set.

[scottf]

Even with bind and the fact that we will always use the server version, that it does not prevent the user from providing a consumer config or a subscribe subject that does not match the server consumer config. When we did not validate, there were times when we would get support questions of why am I getting these subjects, for instance getting all subjects because the filter subject was > when I only used foo in the subscribe api call.
If the api were better and allowed the dev to simply supply the stream and consumer name, it would be acceptable to just skip the validation. In fact this is an important part of our simplification project.

[JorTurFer]

The problem here is that the backoff isn't a valid variable thing. I can update the PR to allow it as variable things, but I think that validate that user isn't providing any extra data than stream name and consumer name could be the best approach.

Somthing like, if you have already set any other value than stream and consumer and you set binding, the code will raise an error (also in other orders like binding first and then other values, etc). In that case, we could give feedback to the users about the problem during the application startup (something like: "Direct binding can't be set if you have already set this property", or, "When direct binding only stream and consumer name can be set", etc) and also we could simplify the code just using the skipping as I have done.

Could this be a solution? It would provide feedback to users about how they should use the client and also prevent the code from these cases of mismatches because we could use the server config

[JorTurFer]

I close this PR on favor of https://github.com/nats-io/nats.net/pull/769