Add support for denote silos configuration

[leafarbelm]

Hi!

This PR introduces the addition of denote silos #63.

If the user wants to create a new source for each silo, they will need to specify the name, key, and path to use in the creation of the source as shown below and activate the consult-notes-denote-mode:

(setq consult-notes-denote-silos
      '(("Silo1" ?a "~/Documents/silos/silo1")
        ("Silo2" ?b "~/Documents/silos/silo2/")
        ("Silo3" ?c "~/Documents/silos/silo3/")))

If consult-notes-denote-silos is nil, it will default to using the denote-directory variable to create the source, maintaining the previous behavior.

Here's a screenshot:

P.S. I apologize for any mistakes, as I am not very well-versed in elisp.

[mclearc]

Thanks for working on this PR! And apologies for taking so long to engage with it.
The feature itself is valuable and addresses a real need from issue #63. However,
there's a problem with the current implementation that needs to be fixed before it can be merged.

The code in consult-notes-denote.el has a merge conflict that wasn't properly
resolved. Lines 90-149 contain both the old and new code interleaved together,
which creates invalid Elisp that won't load. You can see this clearly where
the old defconst consult-notes-denote--source declaration still exists
alongside your new function-based approach.

To fix this:

1. Rebase your branch cleanly against the current main branch
2. Ensure the old defconst consult-notes-denote--source is completely removed
   (not just modified)
3. Keep only your new implementation with consult-notes-denote--source-items
   and the parameterized consult-notes-denote--source function
4. Test that the file actually loads without errors in Emacs
5. Consider adding UTF-8 encoding declaration to the file header: ; coding:
   utf-8-emacs (we just added this to the main files for proper Unicode handling)

Once you clean up the merge conflict and verify the code loads correctly, this
should be ready to merge. The design looks solid.