Support for configuration CDI @ConfigBundle nested classes

[TFaga]

Currently when you declare a CDI bean with the @ConfigBundle annotation to auto-populate its fields with proper values from the apps config, it is only possible to populate primitive types (String, Integer, ...). Like so:

@ConfigBundle("app")
@ApplicationScoped
public class AppConfig {

    private String externalUrl;
    private String externalApiKey;

    // Getters and setters
}

This works great, however with bigger apps the config tends to get very large, so you would rather not have all the values on the same config level and class. Currently the way to solve this is to create multiple CDI @ConfigBundle classes with a different (nested) prefix for each nested level of configuration values. Another way is to manually query every key using the ConfigurationUtil. It also gets very tricky and repetitive if you have a List in your configuration, since you need to query each value one by one.

This needs to be streamlined. I propose we add support for nested custom classes and lists (of primitives and custom classes) when configuring and populating the CDI @ConfigBundle class. This way if such a class has properties that are not primitives KumuluzEE MUST recursively populate then as well along side the already available primitive properties. The same goes for properties that are lists. KumuluzEE MUST also find out about possible cycles in the configuration class tree and warn the developer about them.

In essence, from the developers perspective the following should work automagically:

public class ExternalConfig {

    private String url;
    private String apiKey;

    // Getters and setters
}

@ConfigBundle("app")
@ApplicationScoped
public class AppConfig {

    private String name;

    private ExternalConfig external;

    // Getters and setters
}

@ApplicationScoped
public class AppServiceImpl {

    @Inject
    private AppConfig appConfig;

    public void verifyService() {
        // Prints the value of the nested config param
        System.out.println(appConfig.getExternal().getUrl());
    }
}

[TFaga]

Fixed in #56