Issue title: Plugin Java package names should adhere to Java package naming convention
 Issue body: Namely, we should remove the underscores (which are only recommended as workarounds to special cases, such as avoiding reserved words).

https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html

This is the Java equivalent of https://github.com/flutter/flutter/issues/10073

@mravn-google @goderbauer @collinjackson 
 Comments: 
 Comment 0: Underscores are also used instead of hyphens, which is the rule we're following. We could remove them, but I prefer leaving it up to the user.
 Comment 1: That's only recommended when you're required to do so to avoid a hyphen that exists in your internet domain or a leading number or the like.  By default, they recommend using all lowercase with no underscores -- the list of examples in the [Java 8 spec](http://docs.oracle.com/javase/specs/jls/se8/html/jls-6.html#jls-6.1) shows this:

```
com.nighthacks.java.jag.scrabble
org.openjdk.tools.compiler
net.jcip.annotations
edu.cmu.cs.bovik.cheese
gov.whitehouse.socks.mousefinder
```

I agree that this isn't imperative, but why not publish idiomatic Java?  I think not doing so causes Java developers to give pause (if only for a second), and not in a good way.  e.g. internally in Google, they explicitly call out that underscores are not allowed in package names in their [style guide](http://goto.google.com/java-package-names).
 Comment 2: Please e-mail flutter-dev warning about this change a little while before landing it. Please ask for feedback saying whether it's going to be a problem.
 Comment 3: Removing the underscores from package names in the new project / new plugin templates seems like an easy win because it has no effect on existing apps. We already did this for internal plugins and TBH it was kind of annoying to remember when to remove underscores and when to keep them, but I can see the advantages of being idiomatic.

Hopefully existing plugins can be converted over without breaking anyone if they don't expose any public APIs that clients are supposed to call.

Agree that we should give flutter-dev a heads up before making the change.
 Comment 4: https://groups.google.com/forum/#!topic/flutter-dev/52UuFHCDLMA
 Comment 5: I did not see any issues raised on Todd's post. @tvolkert @collinjackson either of you looking at this refactoring?
 Comment 6: Seems like we should go ahead with it. @tvolkert did you want to take this one?
 Comment 7: Yep
 Comment 8: This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of `flutter doctor -v` and a minimal reproduction of the issue.
{'source': 'GithubIssues', 'repo_name_with_owner': 'flutter/flutter', 'issue_id': 228547647, 'repo_stars': 152526.0}