Give failureaccess an Automatic-Module-Name, and bump its version to 1.0.2 to prepare for a release (which we'll then need to update Guava to use).

[copybara-service]

Give failureaccess an Automatic-Module-Name, and bump its version to 1.0.2 to prepare for a release (which we'll then need to update Guava to use).

I chose an Automatic-Module-Name over an actual module-info, even for this dependency-free artifact, because I can do that without requiring JDK 9+ for builds. Granted, there would be relatively little harm in requiring JDK 9+ for failureaccess builds, since failureaccess isn't part of our normal build process. (Guava's build pulls an already released version of failureaccess.) Still, it's possible that someone is building both Guava and failureaccess with JDK 8, so it may be nice not to break that workflow. Plus, I'm not sure that a proper module definition buys us much (relative to Automatic-Module-Name) when we have no deps? Still, I am a bit tempted, if only to try to shake out remaining issues that module-info might cause our users.

This CL is progress toward fixing #6776 (or "toward working around a Maven bug," if you prefer).

It's also a tiny bit of progress toward modularizing Guava (#2970), since failureaccess is one of its existing unmodularized dependencies.

RELNOTES=Added an Automatic-Module-Name to failureaccess, Guava's one strong runtime dependency.