Legally incredibly dubious, particularly since we don't follow it
strictly as policy, and we have git history instead, which does it right.
This is just a waste of time and a cargo cult.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

This gives a speed boost since rubygems does not have to scan through
every gem in the gemset in order to find the file.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Generated via git ls-files | xargs perl -pi -e "s/(Author.*?<[^@]+@)(?:opscode\\.com|getchef\\.com)(>)/\\1chef.io\\2/gi"

Generated via git ls-files | xargs perl -pi -e "s/[Cc]opyright (?:\([Cc]\) )?((?\!$(date +%Y))\\d{4})(-\\d{4})?([, ][ \d]+)*(,|(?= ))/Copyright \\1-$(date +%Y),/g"

This is an entirely mechanically generated (chefstyle -a) change, to go
along with chef/chefstyle#5 . We should pick something and use it
consistently, and my opinion is that double quotes are the appropriate
thing.

Now we need to switch PolicyBuilder implementations based on several
factors instead of just a single config settings, including content of
the node fetched from the Chef Server.

NB: This is experimental and a bit of a hack. There is no server-side
support, so interactions with the server are coded in a "compatibility
mode" using data bag items and Chef 11 style cookbook version APIs.

The Policyfile PolicyBuilder uses a single document from the server as
the authoritative cookbook version set and expanded run list. Enabling
it will disable support for environments and roles. In addition,
chef-solo and override run lists are currently unsupported, though they
could be supported in the future.