[BUG] `WITH_LIBCURL` is a dead build flag, never defined in any current build system

### Summary

`src/ccextractor.c` (`start_ccx()`) contains a curl initialization block guarded by `#ifdef WITH_LIBCURL`:

```c
#ifdef WITH_LIBCURL
curl_global_init(CURL_GLOBAL_ALL);
curl = curl_easy_init();
if (!curl)
{
curl_global_cleanup();
fatal(EXIT_NOT_CLASSIFIED, "Unable to init curl.");
}
#endif
```

I investigated whether `WITH_LIBCURL` is actually defined by any current build path, and found that it isn't, anywhere. This looks like leftover code from a feature that was deliberately disabled almost 9 years ago and never revived.

### Investigation

**1. `WITH_LIBCURL` is never defined by any build system**

Checked every build path in the repo: `src/CMakeLists.txt` (and other CMakeLists.txt files), `linux/configure.ac`, `mac/configure.ac`, `linux/Makefile.am`, `mac/Makefile.am`, `windows/ccextractor.vcxproj[.filters]`, `linux/build`, all Dockerfiles, and all GitHub Actions workflows. None of them define or pass `-DWITH_LIBCURL`.

The macro only appears in C source under `#ifdef` guards (`src/ccextractor.c`, `src/ccextractor.h`, `src/lib_ccx/ccx_encoders_common.c`, `src/lib_ccx/ccx_common_option.h`, `src/lib_ccx/lib_ccx.h`, `src/lib_ccx/params.c`, `src/lib_ccx/ccx_common_option.c`, `src/lib_ccx/ccx_encoders_curl.c`) and as a comment in `src/rust/src/parser.rs`.

**2. Near-misses that don't actually wire it up**

- **Windows (`.vcxproj`)**: compiles `ccx_encoders_curl.c` and links `libcurl.lib`, but never adds `WITH_LIBCURL` to `PreprocessorDefinitions`. Since the entire file is wrapped in `#ifdef WITH_LIBCURL`, it compiles to an empty translation unit, so MSVC links a curl import lib that's never used.
- **`linux/Makefile.am` / `mac/Makefile.am`**: list `ccx_encoders_curl.c` as a source unconditionally, but `configure.ac` never defines the macro, same dead-file situation.
- **Docker / CI**: `docker/Dockerfile` and several `.github/workflows/*.yml` install `libcurl4-gnutls-dev` as an apt dependency, but the build step is plain `./configure && make`, no `--with-curl` flag exists, no `-DWITH_LIBCURL` is ever passed. This is a vestigial dependency install with no effect on the resulting binary.
- **`linux/build`** (the manual build script, still run today by `.github/workflows/build_linux_systemlibs.yml`): has zero curl flags, no `-DWITH_LIBCURL`, no `-lcurl`.

**3. Git history confirms this was intentional, not an oversight**

2016-09-26 17dd6696 Initial libcurl integration work, linux only
2016-09-28 67a3ed3b Merging curl (introduced the block above)
2016-09-28 8729ae12 Disabling CURL in Windows
2016-09-28 56719e7b Libcurl
2016-12-14 99968362 Removed LIBCURL in linux build script, since that stuff is not complete

Commit `99968362` diff (`linux/build`, the only build script that existed at the time):
```diff
-BLD_FLAGS="... -DENABLE_OCR -DWITH_LIBCURL"
+BLD_FLAGS="... -DENABLE_OCR"
-BLD_LINKER="-lm -zmuldefs -l tesseract -l lept -lcurl"
+BLD_LINKER="-lm -zmuldefs -l tesseract -l lept"
```

The original author pulled the flag about 2.5 months after adding it, explicitly calling the feature incomplete. It was never reintroduced across the subsequent switch to autotools, CMake, or the MSVC vcxproj, confirmed by searching `WITH_LIBCURL` across full commit history.

**4. It's not broken, just unreachable**

If `WITH_LIBCURL` were defined and `-lcurl` linked, this code would build fine. `curl`/`CURLcode res` are declared in `src/ccextractor.h:22-25` under the same guard, and `ccx_encoders_curl.c` references them consistently. It's a self-consistent feature that simply nothing switches on.

**5. Rust-side wrinkle**

`src/rust/lib_ccxr/Cargo.toml` has a Cargo feature `with_libcurl` in the default feature list, a completely separate flag namespace from the C macro. It only gates passing through `curlposturl` config (`parser.rs:1595,1668`) with no actual networking, since the real curl work in `ccx_encoders_curl.c` is never compiled in. This means `-curlposturl` currently parses successfully but does nothing functional.

### Proposed options

I'd suggest one of the following, and I'm happy to take either on:

- **Option A, remove the dead code (recommended, smaller/safer PR):** strip the never-compiled `#ifdef WITH_LIBCURL` blocks, `ccx_encoders_curl.c`, the unused `libcurl.lib` link in the vcxproj, the vestigial `libcurl4-gnutls-dev` installs in Docker/CI, and the Rust-side `with_libcurl` default feature (or the `-curlposturl` CLI surface, if that's also intended to go). This reduces dead weight in the codebase and CI without touching any functionality anyone currently relies on, since none of it is reachable today.
- **Option B, revive the feature:** wire `WITH_LIBCURL` back into CMake/autotools/vcxproj as an actual opt-in build option, so `-curlposturl` and any other curl-dependent functionality become real again. Bigger scope, and probably only worth doing if there's active interest in this feature returning.

I lean toward Option A as the safer first step, with Option B left as a possible follow-up if maintainers want the feature back.

### Would like to be assigned

If this is something the project wants addressed, I'd like to be assigned and submit a PR for it (Option A, unless a maintainer prefers Option B).