Improve Net & Layer Schema

[shelhamer]

caffe.proto defines the schema for all of our models, and has done an admirable job, but it should be broken so that it can mend properly and best serve the research and development of Caffe and our models.

The key improvements are to:

• conslidate network phases into a single net definition Consolidate network definitions #57.
• split LayerParameter into submessages for layer-specific params. This will be self-documenting in terms of what params each layer accepts Split monolithic LayerParameter into per-layer Protobuf Messages #208 Refactor LayerParameter into per-layer Parameter messages #219.
• adopt a protocol for assigning new protobuf fields.

To make this migration in a calm and orderly fashion, we will

• freeze caffe.proto at caffe0.proto and deprecate it
• define a new caffe.proto
• provide a conversion script to cover the changes.

For the assignment of params and protobuf fields, there'll be:

• core param reservations for Net, Layer, and the like (all numbers < 1024) that will be assigned by the core developers. We will accept suggestions, but reserve the choice.
• to avoid overhead and coordinating field requests, we will adopt a distributed system based on the commit hash of the feature branch proposing new fields a proto comment will list the next available field number.
• All field numbers will be assigned at merge time, to not impede development during feature development and pull requesting. In a feature branch, the developer should pick whichever number is next according to dev. Final numbers will be assigned right before more.

Welcome to the world of version < 1.0. The ride never stops.

[shelhamer]

We are posting this issue to further involve the community in the planning of Caffe as an open research project. Please consider in this case that we have thoroughly thought out this change, and desire it for our work, so this will happen in some form though we can all help decide what shape it takes.

[shelhamer]

For the assignment of field numbers, it might be simplest to have a

// NEXT_NUMBER = x

comment in caffe.proto and have mergers resolve the field numbers at merge time with an integration commit. Updating the NEXT_NUMBER line will trigger conflicts for other BVLC members merging at the same time, alerting them that field numbers have advanced and that they should assign fields accordingly.

[shelhamer]

This is essentially done with all-in-one nets and the rest. See #734 for the last details.