Add permission lifetime backend.

[goodov]

Implement permission lifetime logic to track permissions lifetime and revoke them when required.

This change implements time-related aspect of brave/brave-browser#14126, i.e. it handles different lifetime options (24 hrs, 7 days, etc), but does not include support for "permission for this session" aka "revoke permission when all WebContents with eTLD+1 are closed".

The overall logic consists of these steps:

1. Observe UI interactions with PermissionPromptBubble to set permission lifetime in all PermissionRequests currently presented to a user.
2. Pass a permission decision to PermissionLifetimeManager (with all permission data, including content type, origins, lifetime).
3. Store permission origins and lifetime to prefs (PermissionExpirations).
4. Start/update permission revoke timer for a closest permission to be revoked (PermissionLifetimeManager).
5. Revoke permissions on timer hit and reschedule it for a next closest permission to revoke (PermissionLifetimeManager).
6. Observe HostContentSettingsMap to handle any permission changes not triggered via permission prompt dialogs (e.g. manually via Settings or via Page Info UI). This is required to properly update/stop the timer and clean up prefs for permissions we don't need to control anymore (PermissionLifetimeManager).

brave/brave-browser#14126

Submitter Checklist:

• I confirm that no security/privacy review is needed, or that I have requested one
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
• Checked the PR locally: npm run test -- brave_browser_tests, npm run test -- brave_unit_tests, npm run lint, npm run gn_check, npm run tslint
• Ran git rebase master (if needed)

Reviewer Checklist:

• A security review is not needed, or a link to one is included in the PR description
• New files have MPL-2.0 license header
• Adequate test coverage exists to prevent regressions
• Major classes, functions and non-trivial code blocks are well-commented
• Changes in component dependencies are properly reflected in gn
• Code follows the style guide
• Test plan is specified in PR before merging

After-merge Checklist:

• The associated issue milestone is set to the smallest version that the
  changes has landed on
• All relevant documentation has been updated, for instance:
  • https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)
  • https://github.com/brave/brave-browser/wiki/Proxy-redirected-URLs
  • https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections
  • https://github.com/brave/brave-browser/wiki/Brave%E2%80%99s-Use-of-Referral-Codes
  • https://github.com/brave/brave-browser/wiki/Custom-Headers
  • https://github.com/brave/brave-browser/wiki/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

[simonhong]

@goodov Sorry for the late response. I'll review today!

[goodov]

PTAL. It's ready.

[simonhong]

++ for me. Only have trivial nits. 👍

[bridiver]

patches/chromium_src looks ok, but there are some missing dep issues