Fix build against PG16 headers: Value node removal and missing htonl decl

[chenjinbao1989]

pxfuriparser.c and pxf_option.c used the generic Value node type for option-name strings; PG16 split Value into distinct Integer/Float/String/ etc. node types, and makeString()/strVal() now operate on String *, so these failed to compile with "unknown type name 'Value'".

gpdbwritableformatter.c called htonl/ntohl/htons/ntohs without including arpa/inet.h. This used to be a silent implicit-declaration warning but is a hard error under GCC 13's -Werror=implicit-function-declaration.

closes: #ISSUE_Number

---

Change logs

Describe your change clearly, including what problem is being solved or what document is being added or updated.

Contributor's checklist

Here are some reminders before you submit your pull request:

• Make sure that your Pull Request has a clear title and commit message. You can take the Git commit template as a reference.
• Learn the code contribution and doc contribution guides for better collaboration.
• Make sure that CICD workflow is successful.
• List your communications in the GitHub Issues or Discussions (if has or needed).
• Feel free to ask for the cloudberry committers or other people to help review and approve.

[ostinru]

Compilation with cloudberry 2.x got broken. e.g. in Test PXF - fdw

pxf_option.c:473:25: error: unknown type name ‘String’
  473 |                         String     *val = makeString(def->defname);
      |                         ^~~~~~
pxf_option.c:473:43: warning: initialization of ‘int *’ from incompatible pointer type ‘Value *’ [-Wincompatible-pointer-types]
  473 |                         String     *val = makeString(def->defname);
      |                                           ^~~~~~~~~~
make: *** [<builtin>: pxf_option.o] Error 1

[MisterRaindrop]

I see external-table/test/pxfprotocol_test.c file still use Value *v = makeString(uri_no_profile); need modify

[tuhaihe]

Besides the REL_2_STABLE branch, should we add Cloudberry main branch support to the CI workflow?

cloudberry-pxf/.github/workflows/pxf-ci.yml

Lines 38 to 44 in 75cf1f6

	env:
	JAVA_VERSION: "11"
	JAVA_HOME: "/usr/lib/jvm/java-11-openjdk"
	GO_VERSION: "1.25"
	GPHOME: "/usr/local/cloudberry-db"
	CLOUDBERRY_VERSION: "REL_2_STABLE"
	PXF_HOME: "/usr/local/pxf"

Then we can verify if the changes work, right?

[ostinru]

I think that we can support cloudberry 2.x and 3.x in a single cloudberry-pxf codebase with some #ifdefs on C-lang side. This will allow us to compile and use cloudberry-pxf-3.x with cloudberry-2.x. This way we will avoid supporting multiple branches.

[tuhaihe]

I think we can create a branch matrix to test both these branches until 2.X is EOL in the future.