GH-2066, GH-2068, GH-2069, GH-2082, GH-2067 Upgrade Plan panel subscription content

[benstrumeyer]

• Have you followed the guidelines in CONTRIBUTING.md?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Have you added an explanation of what your changes do?
• Does your submission pass tests?
• Did you lint your code prior to submission?

• This PR handles the new onboarding view designs in GH-2066 and steals HTML and SASS from ghostery-website
• Create Yearly/Monthly toggle that changes prices for plus and premium cards
• UpgradePlanView is responsive. Breakpoints are at 740px, and 960px
• See Full List of Features scrolls to table below the fold
• Upgrade Plan sidebar listing is the new default route when the hub is opened
• Already Protected CTA buttons route to Home, otherwise to the the respective product page for yearly/monthly

Tickets:

• https://ghostery.atlassian.net/browse/GH-2066
• https://ghostery.atlassian.net/browse/GH-2068
• https://ghostery.atlassian.net/browse/GH-2069
• https://ghostery.atlassian.net/browse/GH-2082
• https://ghostery.atlassian.net/browse/GH-2067

[wlycdgr]

There's a lot of duplication in the return ( ....) code, which makes the code harder to read and modify than it needs to be and increases bug surface area. As the last push on this PR, let's DRY it out. As one example, instead of inlining all the feature matrix rows, we can define (at file scope) a render helper with the following signature:

const featureMatrixRow = (label, inBasic, inPlus, isSparkle) => (
    <tr>
        ...
    </tr>
);

This makes it possible to condense the ~150 lines of inline <tr> elements to:

{featureMatrixRow(t('hub_upgrade_browser_tracker_blocking'), true, true)}
{featureMatrixRow(t('hub_upgrade_browser_ad_blocking'), true, true)}
{featureMatrixRow(t('hub_upgrade_custom_blocking_preferences'), true, true)}
{featureMatrixRow(t('hub_upgrade_extension_themes'), false, true)}
{featureMatrixRow(t('hub_upgrade_historical_extension_stats'), false, true)}
{featureMatrixRow(t('hub_upgrade_application_tracker_blocking'), false, true, true)}
{featureMatrixRow(t('hub_upgrade_application_ad_blocking'), false, true, true)}
{featureMatrixRow('VPN', false, false, true)}
{featureMatrixRow(t('hub_upgrade_no_vpn_logs'), false, false, true)}
{featureMatrixRow(`P2P ${t('support')}`, false, false, true)}
{featureMatrixRow(`IPv6 ${t('hub_upgrade_leak_protection')}`, false, false, true)}
{featureMatrixRow(t('hub_upgrade_physical_servers'), false, false, true)}
{featureMatrixRow(t('hub_upgrade_unlimited_bandwidth'), false, false, true)}

This is one of the main DRYing opportunities, but there are other big ones. At the least, we should do the same for the same batch of <tr> elements for the mobile view. See if you can identify two or three other spots though! We don't need to get this code perfectly DRY, but we should wring it out at least SOME so it doesn't get that mildew smell.

[benstrumeyer]

Yes, we can definitely do this! I wound up DRYing the matrix rows, cards, CTA buttons, and monthly/yearly toggle and it looks much cleaner now. I declared a few of those in component scope instead of file scope so they would have access to props--let me know if there's a better way to do this. As side note, I like how you're intentionally not passing params to those render helper functions so they evaluate to falsy, I used the same trick in a few of the other functions

[wlycdgr]

Great! This is much cleaner, thank you.
Re: the ones you declared in component scope, with how many props / args we would need to pass to them, I think it's fine to leave them in there. If we get any complaints about performance during QA we know what to try, but I would be very surprised if we did.

[wlycdgr]

lgtm ~