documentation: Update access control for new ref syntaxes

We now support ${username} variables and regular expressions,
so try to document their use a bit.

Change-Id: I3c42fd59b00094eee745de827055794823021618
Signed-off-by: Shawn O. Pearce <sop@google.com>

Documentation/access-control.txt

diff --git a/Documentation/access-control.txt b/Documentation/access-control.txt
index 66b4082..b45853d 100644
--- a/Documentation/access-control.txt
+++ b/Documentation/access-control.txt
@@ -135,10 +135,22 @@
 
 Permissions can be set on a single reference name to match one
 branch (e.g. `refs/heads/master`), or on a reference namespace
-(e.g. `refs/heads/*`) to match any branch starting with that
-prefix. So a permission with `refs/heads/*` will match
+(e.g. `refs/heads/\*`) to match any branch starting with that
+prefix. So a permission with `refs/heads/\*` will match
 `refs/heads/master` and `refs/heads/experimental`, etc.
 
+Reference names can also be described with a regular expression
+by prefixing the reference name with `\^`.  For example
+`\^refs/heads/[a-z]\{1,8\}` matches all lower case branch names
+between 1 and 8 characters long.  Within a regular expression `.`
+is a wildcard matching any character, but may be escaped as `\.`.
+
+References can have the current user name automatically included,
+creating dynamic access controls that change to match the currently
+logged in user.  For example to provide a personal sandbox space
+to all developers, `refs/heads/sandbox/$\{username\}/*` allowing
+the user 'joe' to use 'refs/heads/sandbox/joe/foo'.
+
 When evaluating a reference-level access right, Gerrit will use
 the full set of access rights to determine if the user
 is allowed to perform a given action. For example, if a user is a