Add & Improve XML documentation for public LiteDB API

[TyKonKet]

This PR enhances and completes the XML documentation (/// comments) for LiteDB's public API, focusing on public types, methods, properties, and events. The goal is to provide better IntelliSense support, clearer usage guidance, and to help both maintainers and users understand the responsibilities and semantics of each API component.

All changes are grouped by logical type areas, with each commit covering 1–3 related classes. These include core database classes, mapping types, storage abstractions, and collection interfaces.

Why this change matters:

• Improves developer experience: well-documented APIs make it much easier for consumers to discover and use functionality reliably.
• Encourages correct usage: XML comments clarify method purpose, parameters, return values, and expected behavior.
• Maintains consistency: providing documentation across the public-facing API helps keep the project maintainable and lowers the barrier for contributors.

---

Summary of Documented API Areas

Here is a non-exhaustive list of the API surface that received documentation in this PR (organized by logical groups). Each bullet corresponds roughly to the scope of individual commits:

• LiteDatabase / Core Engine

  • Construction and initialization of the LiteDatabase instance
  • Properties like Mapper, FileStorage, Timeout, UserVersion, etc. ([litedb.org][1])
  • Methods for storage access, collection retrieval, and engine control

• Bson / Document Model

  • BsonDocument: semantics of key-value pairs, valid key names, behavior of nested documents
  • BsonValue types and conversion rules (if present in the documented types)

• Object Mapping / BsonMapper

  • How POCO classes are mapped to BSON documents, conventions for Id fields, null / default handling ([litedb.org][2])
  • Fluent mapping API: EntityBuilder, Id(), Ignore(), Field(), DbRef() ([litedb.org][2])
  • Registration of custom types via RegisterType<T>

---

Impact and Considerations

Backward compatibility:
This change is non-breaking—it only adds or refines XML documentation comments, without altering any logic or public API signatures.

Testing / Validation:

• While documentation doesn’t need runtime tests, it can be validated by building the project and verifying that IntelliSense in IDEs (e.g. Visual Studio) shows the new documentation.
• Optionally, you might consider adding a style or doc-comment checking step in CI to keep the documentation coverage high.

Next Steps / Suggestions:

• Review the XML documentation to ensure all <param>, <returns>, and <exception> tags are used correctly and consistently.
• Possibly generate API reference documentation (e.g., with DocFX or Sandcastle) based on these comments.
• Encourage contributors to document future public API additions using the same style.