For v2, I think we should reconsider which resolvers we include and the 
behavior of the LenientResolver.

Personally, I can't think of a use case for ReturnStartOfIntervalAfter or 
ReturnEndOfIntervalBefore.  These do more than compensate for the gap, as they 
shift the time by an amount other than the DST saving.

For example, if you had a job scheduling system with a recurrence pattern like 
"Daily at 2:30 AM Pacific Time", and you used the ReturnStartOfIntervalAfter 
resolver, the job would run at 3:00 AM on the day of the spring-forward 
transition.  One would commonly expect the job to run at 3:30 AM - the original 
time plus the DST shifted amount.  We need to include a resolver that has this 
behavior.  Perhaps "ReturnForwardShifted" or something like that.

The LenientResolver combines ReturnStartOfIntervalAfter and ReturnLater. 
Thinking of the same use case, it would be strange if a "Daily at 1:00 AM" job 
didn't fire at 1:00 on the day of the fall-back transition just because it was 
waiting for the second instance of 1:00 AM.  We should consider changing the 
composition of the LenientResolver, to ReturnForwardShifter and ReternEarlier.  
This would be a breaking change, but that's something that we could document as 
a v2 feature.