Add support for a "fine" barback log level.

sdk/lib/_internal/pub/lib/src/barback.dart

Index: sdk/lib/_internal/pub/lib/src/barback.dart
diff --git a/sdk/lib/_internal/pub/lib/src/barback.dart b/sdk/lib/_internal/pub/lib/src/barback.dart
index 053a48e75947ff3820ec7f27aa49f110baddebba..fa1ed9e76cd4d3ee3fd858d253b9c186b7217f6e 100644
--- a/sdk/lib/_internal/pub/lib/src/barback.dart
+++ b/sdk/lib/_internal/pub/lib/src/barback.dart
@@ -31,7 +31,7 @@ import 'version.dart';
 ///
 /// Whenever a new non-patch version of barback is published, this *must* be
 /// incremented to synchronize with that.
-final supportedVersion = new Version(0, 11, 0);
+final supportedVersion = new Version(0, 12, 0);

[Siggi Cherem (dart-lang), 2014/02/25 17:56:07]

If it can't be 0.11.2, could we support a wider version range here? (for example
">=0.11.0 <0.13.0 in this case?)

The reason I ask is because we'd like to not release polymer/observe at this
time. We are trying to bundle together a bunch of breaking changes together to
minimize user's disruption.

With the change as it is, we'll have to download the latest version of our
packages, modify them on the side to fix the constraint, and republish them. But
then there would be nothing in the repo history about this hot-fix. I prefer to
avoid it is possible (maybe I'd be less concerned doing that if we could have
our own branches in a separate repo where we could keep track of each version). 

[Siggi Cherem (dart-lang), 2014/02/25 17:59:07]

Looking more closely I realize that that you depend on LogLevel.FINE in the code
so you wont be able to request 0.11.

Another idea - if it's possible to make barback's version 0.11.2, could this
'supportedVersion' start at 0.11.2 instead of 0.11.0?

 
 /// A list of the names of all built-in transformers that pub exposes.
 const _BUILT_IN_TRANSFORMERS = const ['\$dart2js'];