fix(alabaster): change alabaster.nvim repo owner from p00f to dchinmay2

[MrReasonable]

Refs #1802

📑 Description

alabaster.nvim's author renamed their GitHub account from p00f to dchinmay2, and the p00f username has since been registered by a different, unrelated account. The alabaster colorscheme spec still installs it from p00f/alabaster.nvim, which only works because GitHub redirects to dchinmay2/alabaster.nvim. If the new p00f account ever creates a repository with that name, the redirect stops and the old address would point at that repository instead (repo-jacking). Details and evidence are in #1802.

• colorscheme/alabaster/init.lua: p00f/alabaster.nvim → dchinmay2/alabaster.nvim
• colorscheme/alabaster/README.md: same, for the repository link

📖 Additional Information

• Not a breaking change: same repository and history, so lazy-lock.json commits stay valid, and the plugin's lazy.nvim name (alabaster.nvim) is unchanged.
• lazy.nvim updates existing clones' origin to the new address on the next :Lazy restore/:Lazy update.
• Tested with the issue template's repro.lua pointing at this branch: the plugin installs from dchinmay2/alabaster.nvim at the same commit as before, and :colorscheme alabaster loads.
• clangd_extensions.nvim has the same issue: fix(cpp): use clangd_extensions.nvim's current repository (dchinmay2) #1803 (cpp pack) and fix(lsp-inlayhints-nvim): use clangd_extensions.nvim's current repository (dchinmay2) #1805 (lsp-inlayhints-nvim); separate PRs, one scope each.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).