Mark resource as experimental

sdk/lib/core/resource.dart

Index: sdk/lib/core/resource.dart
diff --git a/sdk/lib/core/resource.dart b/sdk/lib/core/resource.dart
index 9bb88d117562999c377ea67da7900d48d6eac34f..de12a30b83a022597cc81e11b85da869f683f5a9 100644
--- a/sdk/lib/core/resource.dart
+++ b/sdk/lib/core/resource.dart
@@ -7,6 +7,9 @@ part of dart.core;
 /**
  * A resource that can be read into the program.
  *
+ * WARNING: This API is under development,

[mit, 2015/08/20 09:31:42]

I am not sure 'WARNING' is the best way of communicating this. I think we should
be more explicit, ala:

* ## Status: Experimental
* WARNING: This API is _experimental_, and it may...

This is similar to this, only slightly stricter:

sdk/lib/mirrors/mirrors.dart uses this:
* ## Status: Unstable
 *
 * The dart:mirrors library is unstable and its API might change slightly as a
 * result of user feedback.

[Lasse Reichstein Nielsen, 2015/08/20 09:40:15]

Interesting. I try to not use any fancy markdown in DartDoc since we haven't
defined what works and what doesn't. I have never used a header in DartDoc so
far, and I have no idea what it will look like. At least I would be very wary of
using it in member documentation - I can see it kind-of makes sense for library
documentation which is often less structured and more "texty".

We have previously used either WARNING: or NOTICE: for that kind of comments
(see Isolate.spawnUri).

[mit, 2015/08/20 09:42:53]

OK leaving out markdown. But still think we should use the word Experimental
which IMHO opinion is stronger than warning.

+ * it may be changed or removed in future releases
+ *
  * A resource is data that can be located using a URI and read into
  * the program at runtime.
  * The URI may use the `package` scheme to read resources provided