Improve mime type handling when import tiddlers

The fundamental change here is in the accepted format for a
tiddler "target" in a recipe. The old format was:

    tiddler: <uri>

Where <uri> is a file path or URI with a scheme (such as an HTTP URL).
The new format maintains support for that but extends it to allow
an option mime type after a single space:

    tiddler: <uri> [mime type]

e.g.

    tiddler: http://example.com/foobar.css text/css

This is to address situations where a remote server will provide
content as text/plain (for security reasons) which you want to
save as a tiddler of a different form. For the most part this is
files delivered from github's raw service. See this group posting
for more details on the problem:

    http://groups.google.com/group/tiddlyspace/msg/cf92406f96e3d6b3

and this posting for more details on the rational for the solution:

    http://groups.google.com/group/tiddlyspace/msg/83c13871bb43b864

If the mime type is provided and the file is not .tid or .tiddler,
then it will be treated as a "special" tiddler, which basically
means a tiddler than needs/wants to set its own type and be either
a binary or pseudo binary tiddler. In the absence of a type in the
recipe, or a .meta file, the type determined by urllib2 will be used.

If the file ends with .js and has no type in the recipe, then it
will be treated as a plugin and (in the absence of a .meta file)
be given a systemConfig tag. To avoid this, provide a mime_type.

I'll get some of this info into the docs after doing the pep8 etc
cleanups.

Also in this are changes to get the tests reflecting modern locations
for the hosting of tiddlywiki content.