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

javatests/com/google/domain/registry/flows/domain/DomainDeleteFlowTest.java

@@ -169,7 +169,7 @@ public class DomainDeleteFlowTest extends ResourceFlowTestCase<DomainDeleteFlow,
             .setClientId("TheRegistrar")
             .setEventTime(eventTime)
             .setBillingTime(TIME_BEFORE_FLOW.plusDays(1))
-            .setEventRef(Ref.create(graceBillingEvent))
+            .setOneTimeEventRef(Ref.create(graceBillingEvent))
             .setParent(historyEntryDomainDelete)
             .build());
   }