Signed-off-by: aklyachkin <aklyachkin@gmail.com>

Signed-off-by: Matt Wrock <matt@mattwrock.com>

* Add license & license_file DSL methods to software.
  * license (String): Sets the license of the software component.
  * license_file (String): The relative path or the url of the license file of the software to be included in LICENSES directory.
    * Can be used multiple times.
    * You can use :project_license as a special value if the software is build related code and if it is using project's license.
* Add license, license_file and license_file_path DSL methods to project.
  * license (String): Sets the license of the project.
  * license_file (String): The relative path or the url of the license file of the project to be included in the file that will be created at project.license_file_path.
  * license_file_path (String): The relative path of the main license file that will be created for the project. Default: LICENSE.

With this omnibus will:
1. Collect all the license files specified in software components into install_dir/LICENSES directory.
2. Create a license file at install_dir/LICENSE which will contain license of the project and license information for all the software components that are being included.

ChangeLog-Entry: A new `omnibus generate changelog` command generates
an opinionated CHANGELOG entry based on metadata in commit messages.

This changeset attempts to reduce the number of places that behavior
substantively changes based on the presence of an external manifest or
not.  Key changes include

- Fetchers now take a manifest entry in their constructor.  The
  manifest has no knowledge of how the entry was created and doesn't
  care.

- Fetchers expect a fully resolved version in the manifest entry.
  Users can construct such a version using the
  #resolve_version(source, version) functions

- Omnibus::Project only interacts with the manifest in 2 ways: (1)
  passes it to the Software when constructing software objects, and
  (2) polling the software collection for their manifest entries to
  present it to the user.

- Omnibus::Software contains the main interaction with the manifest.
  When constructing a Fetcher, it passes its own manifest entry.
  Omnibus::Software#manifest_entry is now the only substantive place
  in the code where we do something different based on whether the
  user provided a manifest entry or not.

This is a rather large commit, but here was no easy way to split it up
into smaller pieces. This commit refactors fetchers to use the abstract
Fetcher class and adds more documentation and consistency to the
fetcher methods.