Support for inlining small methods (independent of they're called inside a loop or not)

tests/language/language_dart2js.status

Index: tests/language/language_dart2js.status
diff --git a/tests/language/language_dart2js.status b/tests/language/language_dart2js.status
index d4d1733c475174cfa2132b94dc34136a6e9694f5..3bd6ec1a96a5c9ec0669d234a34d32d1b095d58d 100644
--- a/tests/language/language_dart2js.status
+++ b/tests/language/language_dart2js.status
@@ -152,7 +152,7 @@ get_set_syntax_test/15: Fail # Fixed by https://chromiumcodereview.appspot.com/1
 get_set_syntax_test/16: Fail # Fixed by https://chromiumcodereview.appspot.com/10915111
 method_binding_test: Fail # internal error: super property read not implemented.
 method_override_test: Fail # cannot resolve type GetKeysFunctionType
-method_override5_test: Fail # Issue 11496
+#method_override5_test: Fail # Issue 11496

[kustermann, 2013/07/15 17:40:27]

Don't know yet, why this test starts passing.

[ngeoffray, 2013/07/16 08:04:45]

From roughly looking at it, I think it's because we have a bug at runtime with
overrides and named parameters. We implement the correct substitution when
inlining, so we inline the right method with your CL. But if we don't inline it,
at runtime we hit the wrong method. The bug is on my radar.

[kustermann, 2013/07/16 13:27:50]

Same here. If I remove this line from the status files, we don't have a single
test which fails on the runtime problem.
A "@DisableInlining()" annotation would here also enable us to test the runtime
functionality.

 abstract_getter_test/01: Fail # instantiation of abstract class
 abstract_factory_constructor_test/01: Fail # instantiation of abstract class
 parameter_initializer6_negative_test: Fail # Issue 3502