Spira.types in threads

Hi! Here's another fix (with tests), this time addressing the use of Spira in "threaded environments".

A common use case would be a Rails app, where a client is given a dedicated thread upon connection. Since:
  a) Spira uses Thread.current to access "types" (a hash which is populated only once when spira/types/* are declared, and
  b) Spira classes are not reloaded during the "grand class reloading of Rails" (e.g. in development mode, where class caching is "off"),
Spira.types fails to get populated, and model classes (that *are* reloaded by Rails) with property declarations like "property :given_name, :predicate => FOAF.givenName, :type => String" cause a TypeError exception (":type => String" initiates a search for the type in now empty "Spira.types").

Generally, I don't understand the rationale behind having spira types stored in a "thread-local hash". Is there a case when the types are different between threads?

Potentially, my fix is thread-unsafe, but as long as Spira.types (or rather, underlying @types) is not modified at the run time (which is the case with Rails and, I suppose, with other sane apps ;-) ), it should be safe enough.

OT: I couldn't find a better way to send separate pull requests and I didn't feel it would've been a good idea to bundle this one with my previous pull request. So while it is marked as to be applied the previous bundle from me, it can be cleanly applied to the current upstream. Please let me know if it doesn't work.