Optimize config loading routine so that we can fit within Deno Deploy constraints

[yorinasub17]

Right now we are loading the config dynamically every time we need to run the rules. This is fine for the tiny example test, but can be problematic in production with arbitrary orgs that might have large and complex rules.

This is especially problematic on Deno Deploy, which has a 50ms limit on CPU time for paid tier, and 10ms time for free tier. If we need to compile ALL the rules, that could quickly consume the runtime and leave room for nothing.

To combat this, we should rearchitect and optimize the config loader as follows:

• Config loading should be a separate task that only loads it in the cache (Deno KV).
• The dynamic lookup at rule exec time only loads from the cache and checks if it is "fresh" by comparing against the head SHA.
  • Implemented in #24
• If the cache is miss, then enqueue the task to load the config and reenqueue the github event with a delay (if possible!).
  • Implemented in #24
• Defer rules loading to a separate task so we have deno tasks that only load one rule.

[yorinasub17]

[Anecdote]
Staging environment seemed to be able to handle the (trivial) typescript rule, so this may not be entirely necessary. Nevertheless it is probably a good idea to implement some of these, such as caching and offloading config loading to a separate process.