Extension:CentralNotice/Notes/Campaign-associated mixins and banner history

Here are some notes about planned changes in CentralNotice and Fundraising banner functionality. We'll improve CentralNotice logging performance, change how Fundraising banners choose to show or hide themselves, and provide more data on users' history of banner and page views to help Fundraising improve banner effectiveness.

These improvement will be rolled together because they have overlapping technical requirements.

Campaign-associated Mixins
Implementation:
 * Campaign-associated Mixins will be RL modules
 * Instead of carrying JS, choiceData will just have the names of any campaign-associated mixin modules needed and the parameters to be used
 * CNBannerChoiceDataResourceLoaderModule will set the mixin modules as dependencies as needed. Note that RL modules are cached client-side, so any given module will only need to be sent from the server the first time a user is targeted by a campaign that needs it. On subsequent page views, the module should be retrieved from the browser's localStorage. Either way, no extra requests.

Non-blocking issues and considerations:


 * Some refactoring of the JS currently in-banner will be needed.
 * We'll try to consolidate bits of JS that are currently used together. It doesn't make sense to have very small modules or to spam the RL module registry.
 * We should only mixinize bits of JS that aren't expected to change too frequently, and make sure that the Mixins' parameters can handle most forseeable tuning needs. Changes in the actual JS will require a deploy.

The other option that was considered was: add commonly used functions to bannerController.lib and include actual small JS snippets in choiceData. However, it looks like the above approach will be more performant overall.

Technical roadmap

 * 1) Implement campaign-associated Mixins
 * 2) Implement category-associated Key-Value storage—a more organized way to keep FR data on the client. First attempt will be to use local storage or something similar, instead of piles of cookies. Try to strike a balance between relative robustness and performance.
 * 3) Determine details of the data pipeline to log from the client. Maybe the first option will be EventLogging to Kafka. Here we might just defer to whatever Analytics and Operations recommends.
 * 4) Refactor bannerController API as needed.
 * 5) Implement the specific Mixins for collecting the data and sending it back - for Banner History Provides feature 1
 * 6) Re-implement/move code for banner show/hide/decide-which-banner-to-show-logic to campaign-associated Mixins Provides features 2 and 4
 * S:RI is turned off and everything is set up so impressions can be had via S:BL Provides feature 3

Features roadmap

 * 1) Banner history via a new logging mechanism.
 * 2) Banner count via S:BL logs: how many times a given banner has been shown (slow to get).
 * 3) Fast to get (sampled?) banner impressions. Turn off S:RI.
 * 4) Don't lose impression after full screen.