[Feature Request]: Per-window buffer scoping (Split-local buffers via Winbar)

### What?

I would like to propose adding support for **per-window buffer scoping** by allowing `bufferline.nvim` to render inside Neovim's `winbar`.

Currently, `bufferline.nvim` renders to the global `tabline`. This feature would allow users to have a dedicated buffer line for each split (window), containing only the buffers relevant to that specific split.

**Proposed Functionality:**
1. **Rendering Target:** Add an option to render the bufferline component in the native `winbar` instead of (or in addition to) the `tabline`.
2. **Per-Window Scope:** When in `winbar` mode, the plugin would maintain a list of buffers specific to that window ID, rather than showing all globally open buffers.
* *Behavior:* When a user opens a file in Split A, it is added to Split A's buffer list.
* *Navigation:* Commands like `:BufferLineCycleNext` would operate within the context of the current window's buffer list only.
3. **Visuals:** Each split would effectively have its own "tab bar" at the top, showing only the files being worked on in that context.

**Example Scenario:**
* **Left Split (Feature Work):** Shows `feature.lua`, `utils.lua`, `types.lua`.
* **Right Split (Tests):** Shows `feature_spec.lua`, `helpers_spec.lua`.
* Cycling buffers in the right split only rotates through the test files, leaving the left split's context irrelevant.

### Why?

**1. Solves the "Global Buffer Soup" Problem:**
Neovim's default buffer system is global. When working with multiple splits (e.g., code on the left, tests on the right), the buffer list becomes a mix of unrelated files. Switching buffers often accidentally pulls a test file into the code split, breaking layout and mental context.

**2. Improved Context Tracking:**
Users often use splits to separate concerns (Frontend vs Backend, Code vs Tests). A global bufferline does not reflect this workflow. Per-window scoping allows the UI to match the user's mental model: "These are the files I am using *here*."

**3. Native 'Winbar' Utilization:**
Since Neovim 0.8+, the `winbar` option allows for window-local status lines. This is the perfect architectural place for this feature, as it is inherently scoped to the window, whereas the `tabline` is global.

**4. Alternatives are Lacking:**
While plugins like `scope.nvim` offer tab-scoped buffers, there is currently no robust solution for *split-scoped* buffers with visual indication. Implementing this in `bufferline.nvim` would make it the definitive tool for complex window layouts.