Adds host parsing

Here's the merge of php-domain-parser and Aura.Uri.  The good news is it passes all the test cases, and I _think_ most of it makes good sense.

Here are my immediate areas of concern:

* **Class Names and Locations**: I'm not sure how you guys feel about having the PublicSuffixList* classes mixed in with the other top level Uri classes.  I'm not sure that makes sense, but I wasn't sure where else to put them so they went there.

* **HttpAdapter Interface and class**: I know that Aura.Http exists, but I also know it's important for each component to be independent. The adapter I've added here is nice and simple, but 1) it's not an Aura.Http adapter and 2) it's lifted from Will Durand's [Geocoder](https://github.com/willdurand/Geocoder) and as such we'd have to give him credit and include his MIT license.  
 * I don't have a problem with crediting Will, but I don't know if you want to have to do that in Aura. We'd have to come up with another solution if not.
 * We'd probably want to add ext-curl as a requirement in composer.json. Does that violate the no external dependency rule?

* ~~**vfsStream dev dependency**: I've added vfsStream as an external dev dependency in composer.json.  This allows for mocking the file system during some tests.  Does that violate the no dependency rule?~~

* ~~**/tests/bootstrap.php**: The tests bootstrap now relies on composer to autoload vfsStream~~

* **Composer vendor binary**: In order to allow end-user updating of the Public Suffix List, I've added a bin directory and have added that bin to the composer.json file.

* **Derivative works**: There are methods in my php-domain-parser that are derived from work in https://github.com/usrflo/registered-domain-libs. Because those are integral to parsing, they're here too.  See Aura\Uri\Host::getRegisterableDomain() and the phpdoc comments for an example.  How should we deal with licensing, attribution, etc in that case?  Or should I refactor the code so that it's not derivative?

I'm sure there are some other areas that we'll need to discuss, and some possible refactoring to do, before finally merging this.  I just wanted to raise the above points because they nagged at me during development.