Fix NICs map reference architecture

The current Fuel documentation contains very strange recommendation according network architecture:
https://docs.mirantis.com/openstack/fuel/fuel-8.0/mos-planning-guide.html#plan-the-network

The main points:
1. First of all I would change our recommendation regarding Management network and recommend to use separate NIC or unite with Admin network, since any other traffic might seriously impact management traffic which can lead to instability of cloud (RabbitMQ, Pacemaker, MySQL clustering and etc)

2. When we use CEPH we should have 2 storage network, instead of using Management network for client traffic
- Storage network.
- CEPH replication network.

So, our recommendation should look like:
- Admin
  * Should be untagged
  * >= 1G
  * Might be united with other networks
  * Ensure no DHCP services are interfering on this segment
- Management
  * Must be separated (except Admin, might be united with Admin)
  * >= 10G
  * Bonding is recommended
- Private
  * Depends on purpose of the cloud
  * If it is not critical might be united with Private net
  * >= 10G (Depends on cluster size, 1G - for small and test clouds)
  * Bonding is recommended
  * Separate NIC is recommended
- Public
  * Depends on purpose of the cloud
  * If it is not critical might be united with Private net
  * >= 10G (Depends on cluster size, 1G - for small and internal clouds)
  * Bonding is recommended
  * Separate NIC is recommended
- Storage
  * Should be separate
  * >= 10G
  * Bonding is strongly recommended
 - CEPH Replication
  * Should be separate
  * >= 10G
  * Bonding is strongly recommended

According these requirements our network map might look like:
http://paste.openstack.org/show/507371/
During the choosing nic mapping for cloud you should keep in mind the main purpose of cloud and make decision based on which kind of traffic will be more significant in this cloud.

If the configuration before the deploy is not satisfied to our recommendations FUEL should generate a warning with risks description and confirmation whether the user is ready to take these risks.