Refactor RelationshipResolver and RebacPolicy to use generic relationship types

[SteelAlloy]

Fix #10

This is a breaking change.

Happy to discuss other solutions to the issue.

[Copilot]

Pull request overview

This PR refactors the RelationshipResolver trait and RebacPolicy struct to support generic relationship types instead of being restricted to &str. This allows users to define relationships using enums or other types, improving type safety and flexibility.

Changes:

• Added generic type parameter Re to RelationshipResolver trait and RebacPolicy struct
• Added Display trait bound to Re for error message formatting
• Updated all implementations and tests to use String as the relationship type
• Updated example code to demonstrate the new API with explicit type parameters

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/lib.rs	Refactored RelationshipResolver and RebacPolicy to accept generic relationship types; added Display import; updated tests to use String type parameter
examples/rebac_policy.rs	Updated example to specify String as the relationship type parameter and convert string literals to String

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[hardbyte]

Thanks for the contribution!

A small addition to the rebac_policy or a new example showing an enum like the Relation { Contributor, Admin } in your issue would be good and serve as documentation for users. Something like

  #[derive(Debug, Clone)]
  enum Relation {
      Owner,
      Contributor,
      Viewer,
  }

  impl fmt::Display for Relation {
      fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
          match self {
              Relation::Owner => write!(f, "owner"),
              Relation::Contributor => write!(f, "contributor"),
              Relation::Viewer => write!(f, "viewer"),
          }
      }
  }

Changes look good, existing &str users now have a slightly worse ergonomic experience ("manager".to_string() everywhere instead of just "manager" but that seems acceptable)

[hardbyte]

Thanks! Made those changes in #14