feat: allow api inferring capabilities

[Gozala]

Implements subset of #254 that can be used to derive set of capabilities provided by one or more delegations.

[gobengo]

Might be good to test that store/* allows store/add

[gobengo]

couple questions above, but no need to block

[travis]

this looks awesome! I've started using it in my local so I'm excited for this to ship. one question - you aren't re-exporting the new function from lib.js so the only way I could use this locally was like:

import * as ucanto from '@ucanto/core'
...
export function canDelegateCapability(delegation, child) {
  const allowsCapabilities = ucanto.Delegation.allows(delegation)
...

which typescript still isn't super happy with (but it compiles and runs just fine):

Property 'allows' does not exist on type 'typeof import("/Users/travis/dev/pl/w3protocol/node_modules/.pnpm/@[email protected]/node_modules/@ucanto/core/dist/src/delegation")'.ts(2339)

could just be a transient TS failure but curious if you think this function is worth re-exporting manually like we do with delegation and isDelegation in https://github.com/web3-storage/ucanto/blob/feat/cap-query/packages/core/src/lib.js ?

[Gozala]

could just be a transient TS failure but curious if you think this function is worth re-exporting manually like we do with delegation and isDelegation in https://github.com/web3-storage/ucanto/blob/feat/cap-query/packages/core/src/lib.js ?

I suspect that error happens because typedefs have not been generated when you linked locally so it still refers to and old version.

In other words I would expect ucanto.Delegation.allows to work fine. For now I don't want to expose this using ucanto.allows as I'm not confident we're going to keep it as is, so making it less prominent seems like a better idea.

[Gozala]

@gobengo I have addressed some of the comments and added more tests, which lead me discover cases where behavior was not accurate. I did bunch of changes to address those cases & it would help to have another review.