PU specific Allocation

[BasicEC]

Created from the PR note.
Originally posted by @ryukzak in #195 (comment)

Problem:
PU allocation (that is implemented in #155) does not take into account types and PU specific information. So if we have 2 different FRAM prototypes we can't say which one is better to allocate.

Alternatives:

• Add PU specific information to allocation options, metrics and take into account this info in estimate function.
• Introduce separate problems (like FramAllocationProblem, AccumAllocationProblem).

Why:

Pros. Second option will allow us to:

• avoid mixing logic in one place (metrics structure contains metrics only related to specific PU, the same is for estimate function)
• make it easier to show metrics in UI (we should show only metrics that related to allocation option)
• make it easier to develop different allocation problems by different people at the same time (less merge conflicts)
• use current AllocationProblem like fallback for PUs that don't have specific allocation problem.

Cons:

• Some common metrics (e.g. mParallelism) will be duplicated in different problems and we will need to make sure they stay consistent.

[BasicEC]

@ryukzak What do you think?

[ryukzak]

As a concept -- briliant. By implementation details can be improved. It will be better to do it by overloaded class instances, where we will have one default implementation, specific to some PU implementation where we need it, and a generic implementation for the class of PU (e.g., pipelined).

In this case, we can remove "concurrency type", because all necessary information will be stored in the instance of AllocationProblem (or how to call it correct?).