Add MongoCounterSupport helper

[anjeongkyun]

Add MongoDB-backed Counter Support

This PR implements MongoDB-backed atomic counters as outlined in GH-4823, split into two logical commits for easier review.

Commit Structure

Commit 1: Internal helper implementation
Commit 2: Public API integration with MongoTemplate

This separation allows reviewing the core logic independently from the public API design.

What's included

Commit 1 - Internal Helper

• MongoCounterSupport (package-private) - wraps findAndModify with $inc, upsert, and returnNew

Commit 2 - Public API

• MongoOperations.getNextCounterValue() - interface method
• MongoTemplate.getNextCounterValue() - implementation delegating to MongoCounterSupport

Usage

long orderId = mongoTemplate.getNextCounterValue("order-id", "counters");
long userId = mongoTemplate.getNextCounterValue("user-id", "counters");

Counter document structure: {_id: "counterName", count: 1}. First call returns 1, subsequent calls increment atomically.

About the implementation

The original issue suggested wrapping the counter pattern in "something like a MongoSequence" and mentioned the relationship to #1842 (external ID generators) which might belong in data-commons.

Implementation decisions

• Named it MongoCounterSupport following existing helper patterns, but open to MongoSequence or alternatives
• Used high-level MongoOperations.findAndModify() instead of the low-level execute() example for consistency with the codebase
• Kept it MongoDB-specific since Pluggable ID generation strategy [DATAMONGO-918] #1842 deals with external ID systems (Snowflake, etc.) while this is about MongoDB's atomic operations
• Internal helper is package-private; public API is minimal and focused

This is intentionally minimal. I'm planning to add custom increment amounts and additional features in follow-up PRs if this direction makes sense.

Looking for feedback

I'd appreciate thoughts on

• Should this be called MongoSequence instead of MongoCounterSupport?
• Does it make sense to keep this MongoDB-specific, or wait for data-commons abstraction work?
• What other functionality would be useful? (custom increments, reset, batch operations?)
• API design: current approach vs alternatives?

Ready to adjust based on your feedback.

Closes #4823

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).