corrections for DexedTheme v2

[FulopNandor]

Dear Pascal,

Please, accept my current pull request, which contains modifications in DXLookNFeel.cpp.

In comparison the related part of its former PR there are the following differences:

1. Because the dexed-pipeline failed yesterday in the case of build-macos due to the deprecation of forEachXmlChildElementWithTagName(), I have replaced it by for-loop based on juce::XmlElement::getFirstChildElement() as initialization and juce::XmlElement::getFirstChildElement() as iteration.
2. I have introduced a method replaceImage() instead of the findImage(). Its reason is that findImage() returns nullptr in that case when DexedTheme.xml refers to a nonexistent image (or the loading of the given image is failed by some other reason). At this point, nullptr will be stored in the corresponding image variable, which results in nothing being displayed on the screen instead of the associated component. For instance, if we specify a broken path in the DexedTheme.xml for the Light_28x28.png˛, e.g.
   <image id="Light_28x28.png" path="nonExsitentSubdirectory/Or/MissingPicture.png"/>
   then all the LEDs disappear from the GUI:
   
   despite that the proper image variable was initialized to the image of a red LED before.

The new method replaceImage() updates the image variable with the new image only if the loading of the new image was successful. So, when a nonexistent image is specified in DexedTheme.xml, the original content of the proper image variable
will not be overwritten, so the default red LEDs are displayed:

Or, if the new image file exists, e.g. GreenLight_28x28.png in the relative path myTheme/, and was loaded successfully due to line
<image id="Light_28x28.png" path="myTheme/GreenLight_28x28.png"/>
in DexedTheme.xml, then its content (green color LED, in this example) are displayed:

Thank you in advance! (hoping that all the checks will be passed now...)