[RORDEV-1229] Make docker-compose resource limits opt-in and host-size aware

[coutoPL]

Container memory limits were hardcoded in base.docker-compose.yml and apm.docker-compose.yml, so every environment got them whether it needed them or not. They are sized for small CI agents and are tight: es-ror capped at 2g against a 1g heap sits at 97–99% of its cgroup for a whole suite run, and one GC spike OOM-kills it. There is no restart policy, so the container stays dead and every remaining spec fails.

This moves mem_limit/memswap_limit out into base.limits.docker-compose.yml and apm.limits.docker-compose.yml, applied as compose overlays only when asked for.

APPLY_RESOURCE_LIMITS accepts true, false or auto:

• false (default) — safe for the ROR KBN Docker-in-Docker flow, where a threaded /sys/fs/cgroup/docker cannot enable the memory controller and a mem_limit prevents containers from starting at all.
• auto — applies the limits only when the host has less than 12 GB RAM, matching the threshold ci/e2e-tests-lib.sh uses in the ROR ES repo. Both workflows set this, so GitHub-hosted runners run unconstrained and small self-hosted agents still get the protection.
• true — always apply.

The ES heap is now pinned explicitly (-Xms1g -Xmx1g) so dropping the cgroup limit does not let it grow unbounded.

Also raises the kbn-ror healthcheck start_period from 60s to 180s: two Kibana replicas boot alongside ES and APM, and on CPU-small agents a replica needs more than 60s to answer /api/status, which was causing docker compose up --wait to tear the stack down before the tests started.

No change for eck environments — they do not use docker-compose overlays.

[Dzuming]

LGTM