Metaissue: Improve initialization

[dmitriy-serdyuk]

@memimo , this is going to be your CCW task. I don't know what's need to be done yet, I just summarize information.

I list here the issues with some summary because the title doesn't always correspond to the discussion.
I found several discussions on initialization:

• #773 where many people are complaining about the current way of initialization and pushing the config
• #740 which proposes a new way to initialize stuff
• #384 another thread on initialization
• #31 and yet another

Other threads which concern initialization:

• #347 discussion on where we should check if every brick was initialized
• #463 enhance initialization schemes printing
• #816 argues about noninitializable sequence and raises a question how we should manage several different properties
• #935 figures out that allocation and possibly initialization is broken with several parent bricks

@rizar , I forgot something?

[rizar]

@memimo , can you please drop by at 3248 to discuss this ticket?

[memimo]

I'm not in the lab today. Still have been finishing my last ticket. Will come by tomorrow.

[rizar]

Summary of the discussion of @rizar, @memimo and @bartvm

1. Initialization schemes are stored in a role -> scheme dictionary attribute of a brick.
2. Each brick has a class attribute which specifies all the roles that its parameters can possibly have.
3. A method Brick.collect_roles collects the set of roles that the brick and its children can have.
4. The role -> scheme dictionary is constrained to only have the roles from self.collect_roles, and this constraint should be enforced when initialization configuration is pushed down the brick hierarchy.
5. We keep attribute based access through __getattr__.
6. We accept <role>_init attribute in the constructor as well as the full role -> scheme dictionary.