+ Using register_uri

[why the lucky stiff]

I've just merged in the last of the major alterations for 1.2.  Two 
things: the foundation for cross-site Ajax and basic Greasemonkey support.

== register_uri ==

First, a minor change: some things were named 'home_url' and 
'register_url' and other things were named 'match_uri' and 
'request_uri'.  I'm no longer using 'url' in the code, everything uses 
'uri'.

The new `register_uri' basically lets you mount a proc on arbitrary 
domains.  So you can mount 'test.js' on every domain your script 
rewrites.  However, a script-specific token is used in the URI.

Let's look at a MouseHole script fragment:

  include_match :domain => "*google.com"
  register_uri "test.js" do |path|
     response['content-type'] = 'text/javascript'
     response.body = "var js_loaded = 1;"
  end

In the above example, we're registering a simple path.  The MouseHole 
script will then be available from 
http://google.com/SCRIPTTOKEN/test.js.  Or 
http://images.google.com/SCRIPTTOKEN/test.js.

You don't need to fiddle with the script token, though.  You can call 
the `reg' method to use these URLs in your code.

  rewrite do
    document.elements['//head'].add_element 'script',
      'type' => 'text/javascript', 'src' => reg('test.js')
  end

For a great example of how this works, check out samples/google-rand.js 
in CVS.  It's a modified version of the MouseHole pinging script Kevin 
posted.

== mount, configure, rewrite, register_uri conventions ==

You can now rely on:
1. The `request' and `response' instance variables are available for use 
in each of the above.
2. Most people won't care, but... Each of the above has a corresponding 
`do_' method, which is a wrapper for its proc.  So, do_rewrite, 
do_configure, etc...  Useful for plugins that want to extend 
UserScript.  (Like StarmonkeyUserScript does.)

_why