Ability to deal in relative times with aperture created lsats

Nobody has claimed this yet.

I noticed some breadcrumbs in the existing code that indicate there was the intention to build in some support for this but best I can tell they are mainly just placeholders for now.

token.go just sets a `TimeCreated` value when [parsing from the challenge](https://github.com/lightninglabs/aperture/blob/master/lsat/token.go#L59-L63) but that's just set to `time.Now()`. As best I can tell, this isn't really persisted anywhere "permanent" on the lsat itself. Then there is [this code](https://github.com/lightninglabs/aperture/blob/master/lsat/token.go#L59-L63) that sets an `IsValid` method on the `Token`. It's only a placeholder now that always returns true. It's not clear to me how the `TimeCreated` value on the token serves any use if it's not encoded directly in the macaroon. I might be missing where this is persisted though.

It seems to me like this would be pretty valuable functionality to have. Without the ability to use aperture as a library, the only way to add caveats via aperture as the author is hardcoded in the config file. As far as I can tell, this makes relative caveat restrictions like an expiration date impossible. The [sample config shows](https://github.com/lightninglabs/aperture/blob/master/sample-conf.yaml#L112) how to add an absolute expiration with a `valid_until` constraint, but I can't see how given the current tooling you could do something like "valid_for=xx_days", which feels much more valuable and flexible to me.

Is there some way to achieve this that I'm missing? If not, what are the chances of getting this support in aperture?

Start by reading lsat/token.go, especially the TimeCreated and IsValid handling, then compare it with the valid_until example in sample-conf.yaml. Determine how relative caveat restrictions could be represented and persisted in the LSAT, and define tests showing that a relative expiration is accepted and enforced.

Written by the indexing model from the issue text.