Fix memory leak when reusing DmtxEncode across multiple encode calls

[94xhn]

Problem

dmtxEncodeDataMatrix() unconditionally does:

enc->message = dmtxMessageCreate(sizeIdx, DmtxFormatMatrix);
...
enc->image = dmtxImageCreate(pxl, width, height, enc->pixelPacking);

without freeing whatever enc->message / enc->image already held from a
previous call on the same DmtxEncode. Reusing one DmtxEncode across
multiple dmtxEncodeDataMatrix() calls (as shown in the repro below) leaks
the prior message and image on every call after the first.

Repro (see #40):

DmtxEncode *enc = dmtxEncodeCreate();
dmtxEncodeDataMatrix(enc, len1, data1);
dmtxEncodeDataMatrix(enc, len2, data2); /* leaks the first message+image */
dmtxEncodeDestroy(&enc);

Fix

Free the existing enc->message / enc->image (mirroring the logic
already used in dmtxEncodeDestroy(), including the pixel-buffer free)
immediately before allocating their replacements. Both fields are NULL
on a freshly created DmtxEncode, and dmtxMessageDestroy() /
dmtxImageDestroy() are already NULL-safe, so this is a no-op on the
first call — no behavior change for the common single-use case.

Testing

• Built the amalgamated dmtx.c with GNU ld --wrap=malloc/calloc/free/realloc
  to count net (unfreed) allocations.
  • Before the fix: encoding twice then destroying once on the same
    DmtxEncode leaks ~6 allocations / ~30KB versus a single encode+destroy
    baseline (isolating library-internal allocations from libc/CRT
    startup noise, which is identical in both cases).
  • After the fix: the reuse case matches the single-call baseline exactly
    (no residual leak), including under a 5-cycle reuse stress test.
• Round-trip correctness: reused one DmtxEncode to encode two different
  strings, decoded each resulting image independently, and confirmed both
  decode back to their original input — the added early frees don't
  corrupt or clobber the freshly created structures still in use.

Fixes #40