Add arena parameter to various APIs

I wonder if it would make sense for all APIs that return JReferences to add an `arena` optional named argument:

```dart
map.put('Hello'.toJString()..deletedIn(arena), helloExample);
```

would become

```dart
map.put('Hello'.toJString(arena: arena), helloExample);
```

Pros:

* You get a hint in the API that the returned value is something you might want to do resource-management for.
* The implementation can use the arena internally, if the implementation somehow throws, then we have no worries about releasing resources.
* It teaches library writers wrapping native resources to make their API work with arenas, instead of having users wrap stuff with arenas as afterthought.

Cons:

* We need to consistently add it _everywhere_ in the API. Not an issue for the generated part, but painful for the `package:jni` handwritten parts.
* Resource management is no longer orthogonal to returning JReferences (or other things which need to be released).
* Library writers will need to write arena parameters everywhere. (But maybe that's a good thing, see last pro.)

@HosseinYousefi This is if we continue the current approach for using arena's. As discussed last week we should also consider:

1. Just letting finalizers do everything (what is the performance penalty?)
2. Relying on some context. With zones in Dart/Flutter, or with widgets in Flutter.