[Tabs]: Add BraveTabFeatures

[fallaciousreasoning]

Resolves brave/brave-browser#43437

Submitter Checklist:

• I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
• There is a ticket for my issue
• Used Github auto-closing keywords in the PR description above
• Wrote a good PR/commit description
• Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
• 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 wiki
  • npm run presubmit wiki, 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/Web-Compatibility-Exceptions-in-Brave
  • https://github.com/brave/brave-browser/wiki/QA-Guide
  • https://github.com/brave/brave-browser/wiki/P3A

Test Plan:

N/A - no changes to existing behavior

[fallaciousreasoning]

note: this is what upstream does. I imagine they'll change it at some point in the future but I think its good to match them for now.

[bridiver]

That's probably because there is a circular dependency in theirs? If we can avoid adding new sources to sources.gni directly, we should

[fallaciousreasoning]

I can put these in their own target, but I'll need to add a dep on //chrome/browser/android and allow_circular_includes_from - is that okay?

[bridiver]

Maybe we should rename the base class so we don't need this patch. So change TabFeaturesAndroid -> TabFeaturesAndroid_ChromiumImpl and call our subclass TabFeaturesAndroid so there are no base class pointers? If we do that here we should do the same for TabFeatures for consistency

[bridiver]

actually we can still name ours BraveTabFeatures* and typedef/using to also be TabFeatures*

[fallaciousreasoning]

I think its better to subclass here - that way if upstream adds some new public methods (highly likely, judging by the look of TabFeatures on desktop) it won't break our overrides.

Additionally if we do that we'll need a std::unique_ptr<TabFeaturesAndroid_ChromiumImpl> on our class to ensure everything its instantiating still exists?