prevent nested templatePlugin from overwriting parent instance

@Seldaek I know dwoo1 is end-of-life, but dwoo2 isn't suitable for me yet. I expect you won't want to merge any more pull requests but if you could comment on this a bit it would be very helpful as I wasn't able to discern the original intention behind appending templatePlugin function names with _$uuid

# Scenario
test.tpl:
```smarty
{load_templates test.sub1.tpl}
<h1>sub1 test</h1>
{sub1 "input1"}

{load_templates test.sub2.tpl}
<h1>sub2 test</h1>
{sub2 "input2"}
```
test.sub1.tpl:
```smarty
{template sub1 input}
    <strong>sub1({$input})</strong>
{/template}
```
test.sub2.tpl:
```smarty
{load_templates test.sub1.tpl}

{template sub2 input}
    <p>sub2({$input}) -> {sub1 $input}</p>
{/template}
```

# Problem
The above example fails on test.tpl's call to {sub1} with `Fatal error: Call to undefined function Dwoo_Plugin_sub1_535188f29fcdb()` because `{load_templates test.sub2.tpl}` copies an instance of sub1 with a different uuid from the cloned compiler back to the original compiler.

# Solution
The best solution I could find was to remove the _$uuid suffix from generated templatePlugin functions and prevent Compiler->addTemplatePlugin from overwriting an existing templatePlugin entry with one with a new UUID. Indexing template plugins by only their name in the templatePlugins array implies the names should be globally unique, so I couldn't make sense of why the function name needed to have the UUID appended. I kept the UUID logic in place for generating the scope though. 

# Unanswered Question
- Why were template plugin function names appended during compilation in the first place and can you think of anything removing it would break?
- Is there a better way to approach this conflict?