Introduce sidebar bookmarks page

[simonhong]

Resolves brave/brave-browser#20500

Applied bookmark part of chromium's side panel to sidebar bookmark panel.
sidebar.mojom is used for interacting between sidebar's bookmarks panel with SidebarBookmarksPageHandler.
Most of webui impls in browser/resources/sidebar/bookmarks are copied from upstream
and modified to show bookmark part only. (side panel's page shows read later and bookmark part both.)
Bookmarks page uses custom context menu by asking to native via Sidebar:ShowCustomContextMenu interface.

Resources from Figma:
https://www.figma.com/file/sS3l8tqUFxt54MEiBTalUI/Desktop-toolbar-and-menu?node-id=9%3A5824

macOS light and dark theme.

Linux light and dark theme.

Bookmark item's context menu

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
• 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, 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:

1. Launch Brave and enable sidebar feature from brave://flags and re-launch
2. Open bookmarks item and bookmark items are displayed properly
3. Test bookmark item's drag and drop and all menus from its context menu

[bsclifton]

Really curious what you think @petemill for the forking from https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/resources/read_later/side_panel/

It's great that we can make any change we'd like (and also we won't get any unexpected changes on Chromium upgrade). But I would be curious if we did want to "rebase", what that would look like. We for sure have to fork any files which are referencing the BRAVE resource IDs - but the logic like keyboard navigation (ex: bookmark_folder.ts, bookmarks_list.ts) I could see getting upstream bug fixes

[bsclifton]

Everything looks great to me 😄 Left a comment about how macOS is weird with no open folder icon... but this is consistent with existing behavior (macOS doesn't have open folder right now)

Really nice work! 😄 It works great with keyboard shortcuts too (both keyboard navigation and using keyboard shortcuts like shift + click)

[simonhong]

Kindly ping :)

[simonhong]

@goodov Thanks for review. All addressed. PTAL again :)

[goodov]

lgtm

[simonhong]

Set CI/skip label as previous run was all green.
Merged after squash.