allow initialize the recipe multiple times

[joanvr]

What's changed?

YamlResourceLoader initializes the lazy loaded recipes with all it's available recipes, so the recipe list gets properly populated with the actual recipes. However, with Environment.scanJar, first we are initializing the recipes from the dependencies ClasspathScanningLoader, which will not have the full list of recipes, thus causing validating errors if the recipe is nested in multiple levels of DeclarativeRecipes from a different jar artifact.

The initialize method right now, clears the uninitialized list of recipes, thus not allowing us to re-initialize again later on (which happens when we are using the same recipe from the "main" YamlResourceLoader, so if the first initialize fails to find some recipes (because from the dependency ClasspathScanningLoader we do not see all the recipes that the "main" one sees), we just loose them, as they are not added to the recipeList, but cleared from the uninitialized one, and permanently having the validation errors, not allowing to call initialize again, because it will do nothing.

What's your motivation?

With this change, the current code on Environment, and YamlResourceLoader works fine loading all the recipes on DeclarativeRecipe with minimal changes.

Anyone you would like to review specifically?

@kmccarp @knutwannheden

Have you considered any alternatives or workarounds?

Right now the code on Environment, and YamlResourceLoader seems a bit more complex than needed, just to get the recipes from a particular jar and not the ones in the dependencies. Maybe we could get rid of the dependencyResourceLoaders by just using a single ClassGraph on the RecipeClassLoader and use the method ClassInfo::getResource() to get the actual package of the class, and filter it then to just return the ones from the "main" jar.
However, any of this requires a huge rework of the environment recipe loading, and maybe the fix on this PR is a simpler and smaller one.