Author simplified regex for Cask keys, for readability and scenarios that already depend on post-processing

The current regex is fairly comprehensive in terms of flagging valid Cask keys only. Recent changes to component ordering allows the regex to ensure conformance between specified secret and optional data sizes and the actual length of the key.

This accuracy and comprehensiveness comes at the expensive of key length and readability. This complex regex also does not handle certain invalid year/month/day combinations (described in #56).

We should author and, minimally, document a simplified regex that does not concern itself with invalid length corner cases, inconsistent data sizer, and invalid expressed timestamps related to differences in the # of days for a specific month.

The text above assumes that performance of our complex regex exceeds the costs of running a simpler regex and performing a subsequent post-processing to verify the key is valid. If benchmarking demonstrates that our complex regex is not performant, we should invert the plan (i.e., utilize the simple regex in code and document the more complex form, which could be useful in situations where detection is enabled solely by pattern matching, i.e., with no API support).

Start by locating the current comprehensive Cask-key regex, its validation tests, and the post-processing path; review the invalid date cases described in #56. Benchmark the existing and simplified approaches, then document the chosen regex and ensure validation still covers size consistency, key length, and invalid calendar dates.