feat: composite primary key support in mysql_replicator (#7)

[y-ken]

Summary

Implements composite primary key support for mysql_replicator, requested in #7.

primary_key now accepts a comma-separated list of columns:

<source>
  @type        mysql_replicator
  query        SELECT tenant_id, id, name FROM items
  primary_key  tenant_id,id
</source>

Change detection (insert/update/delete) then keys on the combination of
those columns, and the Elasticsearch document _id becomes their values joined
by , (e.g. 10,7). A single-column primary_key (the default id) behaves
exactly as before.

Changes

• in_mysql_replicator: primary_key parsed as an array; a row's id is
  extract_id(row) (the array of key-column values), used as the change-
  detection hash key; missing-key check covers every component; delete records
  are emitted as {col => val} for each key column.
• out_mysql_replicator_elasticsearch: builds the _id from one or more
  key columns via join_id. Backward compatible with single keys and with
  mysql_replicator_multi (which still uses a single-column key).
• README documents the feature.

Relationship to #7

This reimplements the idea from #7 (by @k4200) on the current codebase
(which has diverged substantially since 2015) and fixes a bug in the
original: its update branch read table_hash[row[id]] (always nil) instead of
table_hash[id]. #7 can be closed as superseded by this PR.

Tests

• input: primary_key defaults to ['id'], parses tenant_id,id, and
  extract_id returns single/composite values.
• ES output: a composite-key tag produces a joined _id (10,7).

Verified locally on Ruby 3.4 (input 18 tests, ES output 19 tests, 0 failures).

Scope note: mysql_replicator_multi is unchanged (its integer-gap delete
detection assumes a single numeric key); composite support there could be a
follow-up.

🤖 Generated with Claude Code