teal-src/README: Tweak markdown syntax

mod_tokenauth: Fire events on grant creation and revocation

teal-src: Add a README with a few pointers to get started

teal-src: Add keyval+ store type

mod_tokenauth: Fix storage API mistake in revocation

mod_tokenauth: Fix traceback when checking expiry of tokens with no expiry

mod_tokenauth: Refactor API to separate tokens and grants This is another iteration on top of the previous sub-tokens work. Essentially, the concept of a "parent token" has been replaced with the concept of a "grant" to which all tokens now belong. The grant does not have any tokens when first created, but the create_token() call can add them.

mod_tokenauth: Support for creating sub-tokens Properties of sub-tokens: - They share the same id as their parent token - Sub-tokens may not have their own sub-tokens (but may have sibling tokens) - They always have the same or shorter lifetime compared to their parent token - Revoking a parent token revokes all sub-tokens - Sub-tokens always have the same JID as the parent token - They do not have their own 'accessed' property - accessing a sub-token updates the parent token's accessed time Although this is a generic API, it is designed to at least fill the needs of OAuth2 refresh + access tokens (where the parent token is the refresh token and the sub-tokens are access tokens).

mod_tokenauth: return error if storage of new token fails

moduleapi: Add 'peek' to :may() and new :could() helper to suppress logging The current method logs scary "access denied" messages on failure - this is generally very useful when debugging access control stuff, but in some cases the call is simply a check to see if someone *could* perform an action, even if they haven't requested it yet. One example is determining whether to show the user as an admin in disco. The 'peek' parameter, if true, will suppress such logging. The :could() method is just a simple helper that can make the calling code a bit more readable (suggested by Zash).