- Do not only check the step width, but also the time interval between 2
  progress calls. No need to run a PDB call, then update the GUI every
  millisecond or so. This would just unecessarily slow down the plug-in
  for updates which the user won't ever see. From my tests, 20 updates
  per second is plenty enough to have the progression look fluid. No
  need for much more.
- Do not warn anymore on stderr when we drop progress updates. Even if
  just on the unstable builds, such warning is wrong. First because it
  depends on files and machines. Typically a lot of processing could set
  their progress updates relatively to layers. Yet we currently consider
  that 1/256 steps are too small. So what if you have more than 256
  layers? This would make the same code print a warning on big files,
  and none on small files.
  The second reason is that we should not encourage plug-in developers
  to have limited progression updates, but the opposite (progression
  info makes for good feedback), neither should we expect them to
  compute the step size or the time between updates. It's a much saner
  approach to have them only take care about computing relevant update
  steps while our API focuses on filtering these in order to avoid
  overloading the GUI.
  It makes for good progression feedback, sharp GUI while not taking all
  CPU time on it, all this while making it easy on plug-in developers.