Publish more of our written samples to quantum.microsoft.com

[Manvi-Agrawal]

• It might be worth including more samples in samples.mjs, so that they get featured on samples website for greater discovery. Seems this hasnt gotten updated in a long time. Just has 6 examples(Basic, BV, DJ, Hidden-Shift, Random Number Generator).

• Can we move samples not in samples.mjs list to a new repo? I liked classic QDK samples because they were in a separate repo. @tcNickolas has told me previously that monolith helps to simplify the dependencies. I highly doubt that somebody would likely visit this massive codebase to see these curated samples. Currently, they serve little purpose for both for Q# compiler team and people onboarding to Q#. Maybe add new samples repo as a submodule here if folks think it might be useful, although I know git submodules are a bit annoying.

Additional context
Creating separate issue from #1709 for better triaging.

[sezna]

Yeah, it would probably be good to add more of our written samples to the list of published ones. We are not inclined to use a new repository, though, we moved to a monorepo with the modern QDK (whereas the classic QDK had many repos). But, we don't expect samples to be discovered via browsing this repo. We link straight to the correct directory from our documentation and quantum.microsoft.com.

[Manvi-Agrawal]

Yeah, it would probably be good to add more of our written samples to the list of published ones.

Sure, that makes sense. Just to confirm, published samples are primarily sourced from the samples.mjs list, right?

We prefer not to introduce a new repository. We transitioned to a monorepo with the modern QDK (unlike the classic QDK with its many repos).

While I understand the benefits of a monorepo for simplifying build dependencies. But in current structure, I don't see samples outside of 'samples.mjs' list benefitting significantly. For instance, when the @EntryPoint became optional, I recall holding off the sample update unless new version of Azure quantum is released. See #1684 (comment) for more details.

For samples not in samples.mjs list, I think currently it's useful is for samples testing using Rust code to invoke Q# compiler crate. Probably that can be mitigated by using commit hash, but I did not put too much time thinking into this.

Conceptually speaking, Q# samples should not depend on Q# dependencies. In this case, there seems to be CI/CD dependency. If that's the case, wondering if it highlight a bigger issue regarding usability of Q# language for outside users wanting to verify Q# samples.

However, discovering samples through browsing this repo isn't our main goal. We link directly to the relevant directory from our documentation and quantum.microsoft.com.

Thanks @sezna for the additional context. As far as I'm aware, github.com doesn't currently offer the ability to download a specific folder. Additionally, my attempt to download the samples and samples/algorithms folders from github.dev resulted in an error stating "github.dev can't open folder because it contains system files." While tools might exist for downloading specific folders, I haven't personally used any.

My suggestion for a separate repository stemmed more from simplifying the experience for first-time Q# users. In my opinion, someone new to Q# would be most interested in quick-start samples. A separate repo would also reduce unnecessary data consumption (qsharp repo: ~3.6 GB vs samples folder: ~1MB), which could be a significant factor for users in regions with limited connectivity or bandwidth.