Make Cancellation OneTime vs Recurring logic explicit

This CL does a very similar cleanup to Cancellation as the diffbase
does to GracePeriod - see []  It simplifes logic where we
used to overload methods to accept eitherw OneTime or Recurring billing
events refs, despite storing them in separate fields in the entity
(since BillingEvent is not a polymorphic superclass, just a Java-only
one, you can't store them as refs to BillingEvent).

That overloading was ultimately only there as a convenience/hack from
when we added Recurring events and didn't want to go back and change
everything.  It obfuscates what's really going on, requires extra
casting/loss of type-safety, and relies on indirect signals (e.g. the
Billing event reason being AUTO_RENEW) to guess what the right billing
event type is.  That latter aspect will likely no longer work in a
monthly billing world, and was brittle anyways (as came up in the
context of removing the AUTO_RENEW reason - see []
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117165174

java/com/google/domain/registry/flows/domain/DomainTransferRequestFlow.java

@@ -201,7 +201,7 @@ public class DomainTransferRequestFlow
           .setClientId(existingResource.getCurrentSponsorClientId())
           .setEventTime(automaticTransferTime)
           .setBillingTime(expirationTime.plus(registry.getAutoRenewGracePeriodLength()))
-          .setEventRef(existingResource.getAutorenewBillingEvent())
+          .setRecurringEventRef(existingResource.getAutorenewBillingEvent())
           .setParent(historyEntry)
           .build();
       ofy().save().entity(autorenewCancellation);