Suppose you have 256 rollouts, and you batch them into batches B1, B2,
B3, B4 (each of size 64). The order of gradient updates (assuming 3
ppo_epochs) is:

`trlx: B1 B1 B1 B2 B2 B2 B3 B3 B3 B4 B4 B4`

However, what we should actually be doing (and what alpaca-farm and
other rlhf implementations, and standard implementations of PPO do), is

`improved: B1 B2 B3 B4 B1 B2 B3 B4 B1 B2 B3 B4`

It would be even better if we actually produced new random batches at
each ppo_epoch, that would require more refactoring. i.e.:

`optimal: B1 B2 B3 B4 B1' B2' B3' B4' B1* B2* B3* B4*`

This change basically just reorders the learning to make the code use
the `improved` ordering above. It also renames n_updates_per_batch to
n_inner_epochs as that's a more accurate description (especially now),
adjusts forward_time and backward_time to not type-error, and renames
mbs and mb to minibatch and microbatch (as that's what they are).

This way we get better shuffling. Note that we now pass shuffle=True
(implicitly) in the ppo trainer, whereas before we had shuffle=False.
Shuffling is better here, as it means the gradient estimation over
minibatches is less correlated.