Prevent generated imports of dart:_http

[eernstg]

This PR improves on the situation which is reported in #325 (which is that reflectable can generate code that doesn't compile by importing an internal platform library) by special casing dart:_http. It is not obvious that there is a general solution, but dart:_http is only exported by dart:io which implies that we can always replace any import of dart:_http by an import of dart:io.

Also correct some URLs in the top-level README.md.

Also prepare reflectable/builder to be released as version 5.2.1/1.2.1.

Fixes #325

[eernstg]

I've asked for an example in #325 which would allow the new code to be tested.

[sigurdm]

Ideally we find the "canonical" library that exports a given element instead of special casing on imports after they have been generated.

Something like what we do in dartdoc: https://github.com/dart-lang/dartdoc/blob/cb8f442d36abb611d67c8d2fb3e702a641ea32dd/lib/src/model/model_element.dart#L503

Maybe it is ok to land this as a temporary fix though.

[eernstg]

OK! I actually changed the code generator in a slightly different way: It consistently treats 'dart:_http' as an importable library all the way to the end (which is needed in order to ensure that we will generate code for a Cookie class mirror and such). At the very end, the import of 'dart:_http' is changed (as before) to import 'dart:io' instead.

It may seem hacky to do this at the textual level, but I actually think it's a consistent approach.

If I change the construction of domains such that declarations in 'dart:_http' pretend to be declared in 'dart:io' then various other things are breaking.

PTAL!

[eernstg]

Thanks!