Release build cleanup

[mtodd]

Right now we're wired up to use hoe for building and releasing gems. This is why we have Manifest.txt listing all of the files to include in the release gem (came up in #119).

I don't have any experience using hoe, nor do I have any specific complaints against it. I haven't had to build and publish a gem yet so I don't have full context here.

We could either move away from hoe to use just the standard tools (gem build net-ldap.gemspec for instance) entirely, or at least clean up Manifest.txt to exclude anything but what is essential to use Net::LDAP in production usage (hint, spec/ or test/ don't fall in that category). (Which reminds me, @jch, we need make sure lib/net/ldap/connection.rb is included in the gemspec and Manifest.txt if we don't automate this; we'd currently build a gem without it and that wouldn't be good).

@jch also mentioned switching the gemspec to use git ls-files to automate the files config which is a pattern I've seen used numerous other places successfully, and I would like to move that direction.

Thoughts?

cc @schaary @jch @ruby-ldap/ruby-ldap-admins

[jch]

FWIW, I see we're also using hoe-doofus and hoe-gemspec to help with the automation. I think it's great that we have tools in place to ensure we don't put out a bad release, but I'd like some documentation for how a release is done.

In html-pipeline, this is how we do releases: https://github.com/jch/html-pipeline#releasing-a-new-version. It uses the builtin gem tooling, along with a bash script to push up a new tag.

[mtodd]

Let's document and put in practice whatever method we want to use moving forward for the #125 release.

[jch]

Closed via #155 #148