Refactor Batch API

Problem/Motivation

A followup for the issue 🐛 Make non-progressive batch operations possible RTBC as per the suggestion in comment #12 🐛 Make non-progressive batch operations possible RTBC by yched →

Batch "API" is mainly two functions:
- batch_set(): define a set of batched operations to be run by the batch engine. Several independent code branches can their own add batched ops (for instance several form submit handlers defined in different modules).
- batch_process(): launch the execution of the batch sets that were defined earlier during the page request. Batch sets are executed sequentially and stay independent the whole time.

Saying whether processing should happen through the progressbar UI or some other iteration mechanism or just 'in one pass' is something for batch_process()
- it will affect the whole processing, so what if set A specifies 'progressive' and batch B specifies 'non progressive' ?
- it's the caller of batch_process() who knows its own context (form submission, page callback -> UI OK, programmatic form, cron, drush -> UI not OK) and therefore has the elements to decide if execution should be progressive or not. In the generic case, callers of batch_set() have no clue, an it should not matter to them anyway.
- for this exact reason, it's batch_process() that received the option to specify a custom 'iterator' ($redirect_callback) in #555762: Changes to batch API

Adding the 'progressive' option on batch_set() as the patch does is conceptually wrong, it's only 'easier' in terms of API changes (because it adds an optional property inside the $batch_set array param)

I'd much rather have us add the option on batch_process(). 2 options:
1 - light change: 4th optional parameter for batch_process() - no API break
2 - clean and future proof change: rework the current arguments of batch_process() into a single $options array. Note that most batches in contrib are set in form submits, and so should not be affected by the change since i this case Form API takes care of the batch_process() call.

Of course I strongly favor the latter, but that would need a green light for the API break.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet