Configuration option to preserve existing Info dictionary entries (Producer, CreationDate, ModDate) on write

Problem

When pdfcpu writes a document, ensureInfoDict unconditionally overwrites three Info dictionary entries with pdfcpu-generated values (pkg/pdfcpu/info.go, verified against v0.13.0):

d.Update("CreationDate", types.StringLiteral(now))
d.Update("ModDate", types.StringLiteral(now))
d.Update("Producer", types.StringLiteral(v))

There is currently no Configuration switch to suppress this, so a caller that sets these entries through the low-level API (ctx.DereferenceDict(*ctx.Info) + d.Update(...)) always gets them replaced again at write time. (For PDF 2.0 documents the stamping is skipped, but that does not help with existing 1.x documents.)

Use case

We are migrating a document-management pipeline from a JavaScript stack (pdf-lib) to Go, with a hard requirement of byte-level compatibility of the Info dictionary with the existing production output (downstream systems and recipients rely on these fields):

• the original CreationDate must be preserved untouched,
• Producer is a caller-controlled product name (Japanese, serialized as UTF-16BE with BOM),
• the ModDate value/format is controlled by the pipeline.

Apart from this single behaviour, stock pdfcpu covers everything we need — including reading and rewriting PDFs larger than 2 GiB — so we would much rather track upstream than maintain a fork. Today we vendor pdfcpu with a 3-line patch that disables the three d.Update(...) calls, guarded by a byte-level regression test on our side.

Proposal

An opt-in flag on Configuration, e.g.:

// Configuration
PreserveInfoDict bool // default false — current behaviour unchanged

ensureInfoDict would skip the three d.Update(...) calls when the flag is set; default behaviour stays exactly as today. Naming and scope are of course up to you — per-entry granularity would work for us just as well.

Happy to send a PR with tests if you would accept this.