Image toolkit getter

Where do we actually need the image toolkit plugin?

ImageEffect:;applyEffect gets an image and its effect data. But It needs to be able call toolkit specific code.

This can be done by:
- Giving access to the toolkit via the Image object (this issue).

- Passing in toolkit as a separate argument to applyEffect. This would probably make the whole property superfluous. but Image and Toolkit are quite tied to each other, so having this property is not bad. I would rather not see that people start to make new instances of the toolkit just because they cannot access it.

- Adding an apply method to Image. i'm not in favor of this option, I see Image as a dataholder, not a full operational class that can act on itself. (What this means for the save() operation is yet unclear to me.)

Other OO argument to change this from getToolkitId to GetTookit:: Objects should not expose properties of other objects, they may expose objects they are related to though.

I think this is a prerequisite for:
- #2103635: Remove effects from ImageInterface: As soon as you move scale(), etc out of Image, the core effects are cut off of access to the toolkit as well.
- #2073759: Convert toolkit operations to plugins: contrib effects already don't have a counter method in Image,thus already can't work at this moment.

OK, #2103635: Remove effects from ImageInterface gets in first. So removing the __call() from Image can be done here. As soon as we can access the toolkit intance itself (instead of its ID) we don't need to call image anymore to get to the toolkit. Thus

class ResizeImageEffect extends ImageEffectBase implements ConfigurableImageEffectInterface {
  public function applyEffect(ImageInterface $image) {
    if (!$image->resize($this->configuration['width'], $this->configuration['height'])) {

Becomes:

class ResizeImageEffect extends ImageEffectBase implements ConfigurableImageEffectInterface {
  public function applyEffect(ImageInterface $image) {
    if (!$image->getToolkit()->resize($this->configuration['width'], $this->configuration['height'])) {

In all toolkit effects.

- Note that all applyEffect methods need to be refactored anyway in this change, as all do some watchdog logging using the toolkit ID, so doing the renaming to apply here seems a good idea.

- I also wouldn't mind doing the conversion of the arguments to a keyed array here a well. It better be done before we finally go to #2073759: Convert toolkit operations to plugins. That issue is the hardest and thus the patch should be kept the smallest. This patch won't become that much more difficult to review (in all ImageEffect files, you will see a block of deleted lines for applyEfect() and a block of added lines for apply().

- if we decide to do all of this in this issue, we should rename this issue (standardize image effects?)

Updated issue summary.

#2103621: Move GD logic from ImageInterface to toolkit, tie toolkit instance to Image instance, toolkits should no longer be instantiated separately includes a fix for this, and it's needed there for both tests and to expose the toolkit to contrib code. Marking this issue won't fix.