User and group create/update methods now throw exceptions instead of returning false

There are several user and group create/update methods in the API that previously had 2 layers or error handling:

1. If there is a low level error with the response, or the Crowd connection was simply down, an exception was thrown.
2. If there is a real response from Crowd, but that response indicated a simple conflict (the user to update does not exist, or the user to add collides with an existing one), FALSE was returned instead.

The problem with having these 2 layers is that it made code implementing the API quite bloated. This was because special conditional checks were needed for case #2 when typically the handling of the error was no different from that of case #1. Furthermore, because the Drupal context in which the API is being used typically assumes that a layer of validation is taking place before create/update operations (e.g. validate that the user exists in Crowd before updating it), case #2 really was an exception.

To address this the following methods no longer return FALSE, and instead throw an error for all failure cases.

• addUser()
• updateUser()
• updateUserPassword()
• addUserToGroup()
• removeUserFromGroup()

Prior to this change the usage of one of these methods may look like:

try {
  if (crowd_client_connect()->addUserToGroup($username, $group) {
    // No errors or conflicts, continue on...
  }
  else {
    // There was a minor conflict (e.g. the group does not exist). Do some logging or something
    // to catch this that is probably redundant to the catch block below.
  }
}
catch (CrowdException $e) {
  // There was a low-level error (e.g. the connection to the Crowd server is done). Handle it.
  $e->logResponse();
  // Other cleanup...
}

With this change in place this can instead be simplified to:

try {
  crowd_client_connect()->addUserToGroup($username, $group)
  // No errors or conflicts, continue on...
  }
}
catch (CrowdException $e) {
  // There was a problem with the update. The logging method will differentiate the
  // specific REST error code for us.
  $e->logResponse();
  // Other cleanup...
}

Note that:

• This only applies to user and group create/update methods. Other methods that may actually expect some sort of negative response (e.g. authorize($username, $password) can still return a specific FALSE or NULL result to indicate this without an exception.
• Any code using the first pattern will still work fine (this change is generally backwards compatible) because the methods still have a return value upon success.