Udp connection failed due to the out of bytes order when the server and the client run on different ENDIAN CPUs

[RayWindRiver]

NOTE: The iperf3 issue tracker is for registering bugs, enhancement
requests, or submissions of code. It is not a means for asking
questions about building or using iperf3. Those are best directed
towards the Discussions section for this project at
https://github.com/esnet/iperf/discussions
or to the iperf3 mailing list at iperf-dev@googlegroups.com.
A list of frequently-asked questions
regarding iperf3 can be found at http://software.es.net/iperf/faq.html.

Context

• Version of iperf3:
  3.14

• Hardware:
  Client: PowerPC
  Server: IA

• Operating system (and distribution, if any):
  Client: VxWorks
  Server: Linux
  Please note: iperf3 is supported on Linux, FreeBSD, and macOS.
  Support may be provided on a best-effort basis to other UNIX-like
  platforms. We cannot provide support for building and/or running
  iperf3 on Windows, iOS, or Android.

• Other relevant information (for example, non-default compilers,
  libraries, cross-compiling, etc.):

Please fill out one of the "Bug Report" or "Enhancement Request"
sections, as appropriate. Note that submissions of bug fixes, new
features, etc. should be done as a pull request at
https://github.com/esnet/iperf/pulls

Bug Report

• Expected Behavior
  When the server replies the client with "0x39383736", the client receives data "0x39383736".

• Actual Behavior
  When the server replies the client with "0x39383736", the client receives data "0x36373839".

• Steps to Reproduce

• Possible Solution
  Iperf_udp.c iperf_udp_connect: udpate "unsigned int buf" to "char buf [4]"
  Iperf_udp.c iperf_udp_accept: udpate "unsigned int buf" to "char buf [4]"

Enhancement Request

• Current behavior

• Desired behavior

• Implementation notes

[RayWindRiver]

This issue is same as #1467

[bmah888]

Fixed in PR #1468.