Stop capitalizing the proposal description entered by the user

This is broken, even for the default description (which is a date, where
"Tue" becomes "tue").
Improve suggested proposal name on creation so that it's unique

Until now, the default proposal name is "proposal" for all barclamps.
This is fine when the barclamp does not support multiple proposals, but
when it does, it means that the suggested proposal name might already be
in use.

Now we append a _1, _2, etc. string to the suggestion for the new
proposal name. That way, we guarantee that the user can directly create
the proposal.
Add ServiceObject.suggested_proposal_name to define suggested proposal names

This way, we allow barclamps to override
ServiceObject.suggested_proposal_name so that they will use "cluster_1"
instead of "proposal_1".
Fixed raid claiming part

Replaced a wrong next with a simple return as
we are not within the loop anymore.
Merge pull request #989 from tboerger/feature/roxy/raid-claim-fix

[roxy] Fixed raid claiming part
Do not accept / in secure passwords

Otherwise, this conflicts with URI that contain the passwords.
Merge pull request #991 from vuntz/no-slash-in-secure-pw

Do not accept / in secure passwords
Merge pull request #988 from vuntz/better-proposal-name

Better proposal name
Change how we deal with multi-proposals barclamps in list of barclamps

Until now, when a multi-proposal barclamp had no proposal, we were just
displaying a Create button that created a proposal named "default". And
then, later on, we were allowing the creation of new proposals with
different names.

Since "default" is not a great name and people will likely want to
change this, we now directly allow creating proposals with any name.
Merge pull request #978 from vuntz/multi-proposal-ui

Change how we deal with multi-proposals barclamps in list of barclamps
Add conflicts_with constraint

conflicts_with constraint covers the scenario when a node can be
assigned to a certain role only if it is not assigned to any of the
listed roles.

E.g.: A node can be either a pacemaker-cluster-member OR
a pacemaker-cluster-founder, but not both. This would be archieved by
adding these constraints to the model:

{
  "pacemaker-cluster-founder" => {
    "conflicts_with" => ["pacemaker-cluster-member"],
  },
  "pacemaker-cluster-member" => {
    "conflicts_with" => ["pacemaker-cluster-founder"],
  }
}

The conflicts_with value can contain more than one role in the case of
multiple conflicting roles:

{
  "roleA" => { "conflicts_with" => ["roleB", "roleC"] }
}
Add conflicts_with constraint type to ServiceObject

conflicts_with constraint allows specifying one or more mutually
exclusive roles for a given node and role.

E.g.: a node can be either a pacemaker-cluster-member or
pacemaker-cluster-founder, but not both.

The patch also adds tests for existing constraint types.
Merge pull request #992 from bkutil/conflicts_with_constraint

Add conflicts_with constraint