SEL: add sugar atom selection based on GLYCAM residue names

[MadhankumarAI]

What:
Add a sugar atom selection based on common GLYCAM residue names.

Why:
MDAnalysis currently provides residue-based selectors such as protein but lacks an equivalent selector for carbohydrates. This change adds a minimal, explicit sugar selector using well-documented GLYCAM06 residue names, without relying on heuristics or pattern matching.

Notes:

• The initial residue list is intentionally limited to common GLYCAM hexoses (Glc, Gal, Man) to establish the selector pattern.
• The implementation mirrors existing selector logic in this module, including use of topology-backed residue name lookups.
• Additional sugars, aliases, or broader coverage are intentionally deferred for follow-up discussion.

PR Checklist:

• Tests added for positive and negative selection cases
• No public API changes
• No behavior changes outside selection logic
• Docs (intentionally deferred)
• Changelog (not required for this change)
• Issue referenced (Closes Implementation of SugarSelection #4790)

---

📚 Documentation preview 📚: https://mdanalysis--5209.org.readthedocs.build/en/5209/

[github-actions]

Hello there first time contributor! Welcome to the MDAnalysis community! We ask that all contributors abide by our Code of Conduct and that first time contributors introduce themselves on GitHub Discussions so we can get to know you. You can learn more about participating here. Please also add yourself to package/AUTHORS as part of this PR.

[MadhankumarAI]

This is a draft PR for early feedback.

The scope is intentionally minimal to establish the selector pattern before extending coverage. Happy to adjust naming, residue coverage or placement based on maintainer input.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.72%. Comparing base (4c12f15) to head (7f5951e).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #5209      +/-   ##
===========================================
- Coverage    92.72%   92.72%   -0.01%     
===========================================
  Files          180      180              
  Lines        22475    22483       +8     
  Branches      3190     3190              
===========================================
+ Hits         20841    20848       +7     
- Misses        1177     1178       +1     
  Partials       457      457              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[IAlibay]

I'm going to block this to ask for more information:

1. You didn't answer/deleted the AI / LLM clause - did you use one for this work?
2. What does this PR do that isn't implemented in the PR it supplements?
3. Why should this PR supplement #4790?
4. Please add tests before asking for feedback.

[MadhankumarAI]

I'm going to block this to ask for more information:

1. You didn't answer/deleted the AI / LLM clause - did you use one for this work?
2. What does this PR do that isn't implemented in the PR it supplements?
3. Why should this PR supplement Implementation of SugarSelection #4790?
4. Please add tests before asking for feedback.

@IAlibay thanks for bringing this to my attention . I missed the earlier implementation when I started working on this.

Before addressing the overlap, to answer the AI question clearly: I did not use an AI to generate the code or tests in this PR. The implementation and tests were written and validated manually by understanding the existing code base.

Considered in relation to #4790, I think that it represents a comprehensive fix, especially with regard to residue representation, naming conventions supported and test data obtained from GLYCAM and PDB. The point of my posting was not to reproduce that excellent effort but rather to think about a simple implementation of a selector for the issue #4563

In light of all this overlap, this pr is not an attempt to replace or compete with what was done earlier. Instead, what actually happened was that this became a redundancy within the problem space which I realize isn't necessarily where I want my efforts spent, given what already exists.

Well, I have now added the tests as requested, but in light of events, I’m completely happy to close this pr or rework it to support the existing implementation instead for example by helping with additional tests or follow-up refinements if that would be more useful to the project.