Consider further refactoring of the Policy package

For context, this issue came out of discussions surrounding #7218 and #7200. At current, the policy package, at the highest level, accomplishes two things: Determines whether a given domain or domains are "good" or not, by checking that it is "well-formed" and it is not present on our blocklists. Also, it reports which challenge types are currently enabled.

ValidDomain, ValidNonWildcardDomain, and ValidEmail

The various utility functions used to accomplish the aforementioned domain validation are also exported for external use. Among these, the ValidNonWildcardDomain function is directly utilized inside of ValidEmail, which is, itself, exported for application in the Registration Authority, expiration-mailer, notify-mailer, and contact-auditor.

PROPOSAL: Most of these applications are only loosely, if at all, related to policy, it makes sense to move ValidDomain, ValidNonWildcardDomain, and ValidEmail to the core package.

policy.AuthorityImpl.WillingToIssue

The WillingToIssue method not only performs all of the domain validation above but it also validates that each name is not present on our blocklists. Calls to this method in a single issuance are as follows:

• At Order time in the RA, called via NewOrder
• At Finalize time in the RA, called via VerifyCSR in validateFinalizeRequest
• At Finalize time in the CA, called via VerifyCSR in issuePrecertificateInner

PROPOSAL: Because WillingToIssue is a method of policy.AuthorityImpl, the blocklist configuration for this struct must be present in both the RA and the CA. Replacing the call to WillingToIssue with a call to core.ValidDomain in VerifyCSR would give us most of the functionality and allow us to remove blocklist configuration from the CA.

policy.AuthorityImpl.ChallengesFor, ChallengeTypeEnabled, and CheckAuthz

Changes to these methods are probably best left to #5913. None of these are called outside of the RA so they're probably best left on the existing struct or possibly moved to RegistrationAuthorityImpl.

Start by reading the policy package and the mentioned call paths through NewOrder, VerifyCSR, and issuePrecertificateInner, then compare the exported validation helpers with the AuthorityImpl methods. Done means reaching agreement on the proposed policy/core boundary, relocating the applicable validation responsibilities, and preserving the RA and CA issuance behavior.