Add ledger-specific resource endpoints

[bplatz]

Summary

This PR adds ledger-specific resource endpoints that match the Fluree serverless API pattern. The implementation allows ledger names to be part of the URL path, eliminating the need for 'ledger' fields in request payloads.

Changes

• Added new handler fluree.server.handlers.ledger-resource for processing ledger resource operations
• Implemented URL path parsing to extract ledger names (including those with forward slashes) and operations
• Added middleware for automatic ledger name extraction from URL paths
• Updated router configuration to support catch-all routes with conflict resolution
• Fixed cyclic dependency between handler and ledger namespaces
• Added unit tests for path parsing logic

Endpoints Added

• /{ledger-name}/:create
• /{ledger-name}/:insert
• /{ledger-name}/:upsert
• /{ledger-name}/:update
• /{ledger-name}/:delete
• /{ledger-name}/:query
• /{ledger-name}/:multi-query
• /{ledger-name}/:history
• /{ledger-name}/:commit

Backwards Compatibility

All existing endpoints remain functional. The new resource endpoints coexist with the current API structure.

Testing

• Added unit tests for ledger path parsing logic (12 assertions, all passing)
• Verified existing tests continue to pass

Notes for Review

This is a draft PR for team feedback and review. The implementation focuses on matching the serverless API pattern while maintaining full backwards compatibility.

[dpetran]

I've pulled this branch down and gotten it rebased on main. I feel like it would be a lot simpler (less code, less edge cases) and faster, if we could do /query/<ledger-alias> instead of having to do all the ledger-resource parsing. The performance benefits would come from being able to take advantage of reitit's conflict-free router (which allows compile-time optimizations) and from eschewing all the complex string parsing we'd need, as well as the complexity of the bespoke ledger-operation data structure that we need to interpret.

[bplatz]

/query/<ledger-alias> instead

I don't disagree and not sure the right path.

My thought in the way it is is that I should be able to go do http://foo.com/mydb and if I was authorized, see a web page show up. When I query, I just query the same URL... (this is why you don't need /:query appended for querying, but all other ops you need it). Also in federated queries I could just list URLs like the above (as prepending them all with /query/ seems awkward in that case... but could certainly work.

I guess I was focused on the ledger being the "resource" and then operations on the resource are appended to it (or in theory could be use with REST verbs.. but I stayed away from that pattern as it seemed to add complexity where true REST isn't used all that often... so more explicit URLs I think make things more clear.

Anyhow, that is why I opted for that pattern FWIW.

[dpetran]

I've got this implemented and merged in #186

It uses this URL format:

/fluree/ledger/<ledger-alias>/<op>

This preserves the ledger-as-resource semantic avoids the performance hit of the conflicting routes.