Integrate hs-ucan into the server

[expede]

No description provided.

[matheus23]

My thinking of how we can break down this work.

Since hs-ucan is compatible with 0.3 ucans consumer-wise (you can consume 0.3 UCANs, but not produce them),
we can do this:

• Implement DelegationSemantics and IsResource & IsAbility for the wnfs resource & ability, using the parse*V_0_3 functions
• In all exisitng v1 and v2 routes, check that the incoming UCAN version is 0.3.*. Because of that we can safely assume the UCAN is a simple chain & walk that chain to get the root issuer. (No need to e.g. change the data-root update route to include the username/did)
• TODO: Figure out what to do with the fission CLI in this state. We can't generate 0.3 UCANs with hs-ucan, so, that's left to be figured out. Maybe just upgrade the fission CLI to write new UCANs, but post them to old routes. That type-checks, but will always fail validation. Later we can switch to new v3 routes.
• Implement v3 routes. This needs a little more design. E.g. the whoami route wouldn't make sense anymore. The data-root update route should take the username/did as another parameter. The v3 routes should only accept 0.8.* UCANs (at the top level of the UCAN chain).
• Switch the fission CLI's routes to v3(?)

Following that, we can upgrade to ts-ucan in webnative and the auth lobby. And maybe we should already do that in parallel to us upgrading the fission CLI, because otherwise you won't be able to link CLI -> Browser. This is probably not a zero-downtime plan, but I think that's fine, given that this is only "downtime for linking CLI -> Browser".