Update threetenbp to v1.3.4 and use ZoneRulesInitializer for on-demand initialization

[mmallozzi]

With this change, almost nothing will need to happen at application startup - the initializer (along with the application context) will be registered, but any other library code execution will be deferred until ZoneRulesProvider is initialized when ThreeTenBP first needs to make use of time zone data later on in execution. Most notably, this prevents ServiceLoader from being used to try to load time zone data, as that was a big performance hit within ThreeTenBP before on Android devices.

[JakeWharton]

Did you see #52?

[mmallozzi]

Ah nope you beat me to it! This approach is what I had in mind when I made those ThreeTenBP changes, since it would allow initialization to be deferred until necessary, rather than paying the initialization cost on every app startup. In larger apps where features requiring time zone data won't always be executed, this makes a big difference. Using the DO_NOTHING version helps to bypass ServiceLoader which is certainly a big performance killer, but using a custom initializer would allow you to make the entire thing lazy. It may actually be a good idea to provide two different initialization options, like init() and initLazy(), so that app developers can decide whether they want to slow down startup in exchange for good response time later, or do almost nothing at startup but risk some jank later when the data is needed.

[mmallozzi]

Thoughts here? In my own code I've been using lazythreetenbp which incorporates similar changes to this PR and has been running stably for a couple months, but which also addresses #23 for lazy loading.