Make JobScope and StepScope not rely on static JobSynchronizationManager and StepSynchronizationManager

Similar to closed issue https://github.com/spring-projects/spring-batch/issues/1126 and open issue https://github.com/spring-projects/spring-batch/issues/4774

Expected Behavior

My application is multitenant and uses several databases, one per tenant. Each database has its own schema with the Spring Batch-related tables.
The application also uses beans in JobScope and StepScope.
I expect those scopes to work as expected.

Current Behavior

JobScope and StepScope are managed using JobSynchronizationManager and StepSynchronizationManager.
Those can be seen as a ConcurrentHashMap mapping from JobExecution or StepExecution to the scoped bean instance.

Job/Step execution is registered by Spring Batch via static method calls (Job, Step).

For my use case, this causes runtime error. As I have several independent databases, each has its own sequence and can generate the same id at the same time, causing collisions in the static ConcurrentHashMap and in the best case it makes the job fail due to type errors when retrieving a bean, at worst I could by chance retrieve a scoped bean of the correct type and mix data from different tenants.

Context

My current workaround is to use classpath precedence to provide my own version of the {Job|Step}SynchronizationManager that uses a composite key, consisting of a pair (TenantId, entity) instead of just entity.

Start with JobSynchronizationManager and StepSynchronizationManager, then trace the registration calls in AbstractJob and AbstractStep referenced by the issue. Read the related issues 1126 and 4774 for prior context. Done means JobScope and StepScope remain isolated when independent tenant databases generate identical execution IDs, without relying on the current static mapping.