update to PHP 5.3 syntax
use associative array

the old code was beyond readable - the data we needed from that regex
has outgrown the point where a numeric array was still even remotely
readable
change terminology

in order to move to handling tags with content, let's use the term
"work unit" for the thing sacy works on. This could be a file or a bunch
of content to work with.

Right now, it's just a file. This patch doesn't change the functionality
at all aside of renaming methods and variable.

And moving stuff out of the huge smarty_block_asset_compile function
one less global function

this is only being used by the extractor, so let's move it there
squash into work unit extractor
rename 'name' member to 'file'

a work unit will have wither 'file' or 'content' members depending on
whether we have a file to work with or not
dry up category naming

also add an indicator whether we are dealing with a file or not to the
current categorization. Currently, of course, file is never unset, but
we're going to use this to denote an inline work-unit
fix typo
remove dependencies to smarty

we only really passed around that smarty instance in order to call
trigger_error() on it which is actually not even available in Smarty 3
any more.

By having a smarty agnostic backend (not there yet), sacy could even be
used in a smarty-less environment at some point.

This also gets rid of the remaining two global functions (aside of the
block function of course)
fix copyright
more renaming to work_units

next step will be the big refactoring
create a sacy namespace

as we are now requiring PHP 5.3, we can get rid of the ugly sacy_ prefix
in front of all types and just use real namespaces
handle work units without files

while we are still not accepting tags with content, we now have the
framework in plave to handle work units that are based on contents, but
not on files.

In order to do change detection, we are using the md5() of the content
to sacify and then use a very simple file-system backed cache (you can
provide a different class using a define() if you have something else
already - like memcache).

Before coming up with this implementation I tried various reworks of the
whole sacy concept, but what ever I came up with: It was never totally
correct (sacy never was - there are issues when mixing sacyfiable and
non-sacyfiable tags), still messy and producing tons and tons of small
objects in the process.

So in the end, I kept the implementation simple
added sample config file
assume type/javascript for typeless <script> tags

this is what browsers to too and the type attribute, like the lang one
before it is going the path of deprecation, so let's not enforce its
presence for sacy to work on the tag.

Principle of least surprise at work
add support for inline-tags
fragement-cache depending on debug-mode

I made the same fix for the file based solution. This allows for
toggling _sacy_debug between 0 and 3 while always ensuring correct
fragment output
update NEWS

correct chronological order. Document support for transformation of
inline tags
get rid of FragmentCache interface

duck typing seems to be a better method here as having to implement the
interface in the library-using code would seriously miss with smarty's
autoloading ability (i.e. the consumer would have to manually include
the file to make the interface known).

As this is an advanced feature which requires an additional define(), I
think we can live with actually just duck-typing this one
big documentation update