RELEASE 2.4.1: Update To Release Notes Editor Contents

This is an improvement to the recent release 2.3.0.

Now, the release notes file contains a copy of the current changelog for reference - it gets stripped out of the notes afterwards. You will see something like this:

<Enter your release notes here>

####<CHANGELOG> This is for reference only - this line and all following lines will be stripped from 
the release notes.

(Changelog entries...)

RELEASE 2.4.0: Configurable Post-Release Email Recipients

The setting 'plugins.release_hook.emailer.recipients' controls who is emailed when packages are released (if using this, don't forget that you also need to activate the 'emailer' hook type - see setting 'release_hooks').

Previously 'recipients' could only be a list of email addresses. This release adds support for setting this to a YAML file, which gives finer-grained control over recipients.

See the new config setting description here:

https://github.com/nerdvegas/rez/blob/master/src/rezplugins/release_hook/rezconfig#L11

And an example recipients config file here:

https://github.com/nerdvegas/rez/blob/master/src/rezplugins/release_hook/emailer-recipients-example.yaml

Please don't forget that you can also override the 'recipients' setting individually in any given package.py, like so:

# in package.py
with scope('config') as config:
    config.plugins.release_hook.emailer.recipients = "/.../recipients.yaml"

Add Release Notes Editor

Merges PR:
#293

Optionally open an editor when rez-release is run, so the user can enter a human-readable release note. Previously this could only be done using the -m flag.

PLEASE NOTE:
To use this feature you must set the new config setting prompt_release_message to True; it is left False by default.

Broken release no longer creates broken package

Previously, an error in a build (CMakeLists.txt) could result in a partially installed package. Often in this situation, the package.py is not present, because this is the last thing to be written/updated during a build or release. This would then cause resolves to fail with errors like "Missing package definition file...".

This release addresses the problem. During a package install, a hidden '.buildingXXX' file is created, where XXX is the package version being built or released. After a successful install, this file is removed. When resolving, rez notes these files and does a more thorough check of those packages (ie, checks for package.py file) to ensure they are not partial installs. Packages that fail the test are silently ignored.

This release addresses the following issues:
#323

Added arbitrary package attributes

You can now include any arbitrary attribute in a package.py. It will remain in the package definition on install/release (previously it was stripped), and can be accessed like 'Package.mycustomattrib'.

Motivation: The need to perform custom post-package-release actions depending on certain attributes. For example, I have a post process that generates documentation on a server, but I don't want to do that for 3rd party software, and in those cases I will add an "external = True" attribute to the package.py.

First official 2.0 release

Many recent PRs have now been merged, and a good chunk of the documentation has been bought up to speed. The API and CLI tools have been stable for some time now, and API breaking changes are rare and always reported on the google groups forum. We're ready for 2.0.