Add basic documentation and usage examples

[lukaferlez]

Summary

Adds a README overview/quick-start plus a full docs/USAGE.md guide covering:

• Package overview (Simpleverse.Repository vs Simpleverse.Repository.Db)
• Entity mapping conventions (Dapper.Contrib attributes: Table/Key/ExplicitKey/Computed/Write/Immutable)
• TypeMeta configuration and how it's resolved via Table<T>
• Repository/connection setup (SqlRepository, DbRepository)
• Defining an Entity<TModel, TFilter, TOptions> with custom filtering
• Common usage scenarios: ListAsync (including filters, projections, and tuple joins), GetAsync/ExistsAsync, and Add/Update/Upsert/Delete

Test plan

• Docs-only change (README.md, docs/USAGE.md) — no source code touched.
• Verified all referenced types/members (TypeMeta, Table<T>, Entity<TModel, TFilter, TOptions>, DbRepository, SqlRepository, ListAsync overloads, etc.) exist in the current codebase by reading the relevant source and test files (e.g. Meta/TypeMeta.cs, Table.cs, DbRepository.cs, Entity/Entity.cs, Db.Test/SqlServer/Entity/EntityTest.cs).
• Did not build/run the solution (requires a live SQL Server for the test suite); this is a documentation-only change with no compiled code.

Risks / things to double check

• Please double-check the example snippets against your intended public API surface/examples — I cross-referenced them against existing usages in the test project, but a human familiar with the intended "getting started" narrative may want to adjust emphasis or add more scenarios (e.g. bulk operations, application locks, change tracking) which are only mentioned as a pointer to the test suite.
• No code was changed; risk of build breakage is effectively zero.

Closes #21

[lukaferlez]

For a quick start IdentityFilter class is not neccessary. Assuming that the user will only filter on the actual entity columns then the Identity class with "virtual" properties can be used and the entity will do the filter mapping automatically.

The separate "filter" class and mapping is only necessary if we are changing/expanding the filtering beyond the basic columns.

[lukaferlez]

Addressed the review feedback in 7195dad:

• README.md (line 41 comment) and docs/USAGE.md (line 115 comment): Simplified the quick-start example to use the model itself as the filter type (Entity<Identity, DbQueryOptions>) instead of a separate IdentityQueryFilter class + Filter override. Since Identity has virtual properties, the base Entity.Filter implementation maps them automatically. The custom filter/override pattern is kept in USAGE.md, but now framed as an advanced scenario for when filtering needs to go beyond basic column mapping.
• docs/USAGE.md (line 21 comment): Rewrote the "Core concepts" bullets to describe the actual design goals (datasource-agnostic repositories, compile-time type safety, free choice of implementation details) instead of the previous implementation-detail-focused text.

[lukaferlez]

Declaring an entity is not neccessary, the simplest version is

var entity = new Entity(repository, new Table("I"));

Why would one want to declare the IdentityEntity? To avoid using complicated type names such as Entity<Identity, IdentityFilter, DbQueryOptions> all over the place when things get extended. The more complicated version should be noted in the usage.md with the reasons.

We need a task to further simplify this to Entity(repository, string tableName), as well.

[lukaferlez]

Addressed the remaining review feedback in 1d8fe44:

• README.md (line 44 comment): Removed the dedicated IdentityEntity subclass from the quick-start example. The simplest form — new Entity<Identity>(repository, new Table<Identity>("I")) — is now used directly.
• docs/USAGE.md (line 145 comment): The 'Defining an Entity' section now leads with the minimal Entity<T> instantiation as the recommended quick-start approach, and reframes the IdentityEntity subclass pattern as a convenience for when type names get long (e.g. once a custom filter is introduced) or when behaviour needs to be extended beyond the base Entity class.