Move Script, Sound, and SoundListener ECs to TundraCore

[Stinkfist0]

These are very fundamental ECs and there's no point to having them as optional.

[jonnenauha]

+1. Sound is already a subfolder there so will go in neatly. Less separate projects/static libs to build the better :)

[Stinkfist0]

Started looking into this; actually Sound and SoundListener are a bit problematic due to the Placeable dependency, but Script can be moved easily at least.

[jonnenauha]

I've been saying a long time that we need to also move Placeable to core as an interface.

Just like IRenderer but IPlaceable that gets inherited and some basic interface implemented by the ogre EC_Placeable.

Until we do this

• We cant change our renderer (this requires doing interfaces for bunch of other ECs as well)
• Everything is married to linking OgreRenderingModule which is a pain. Most things might be happy with getting/setting Transform via IPlaceable.

I'm sure EC_Sound would be happy with very simple functionality aka. ent->Component<IPlaceable>()->SetPosition(x,y,z); and ->Position().

[Stinkfist0]

Placeable is the most essential EC and should be in TundraCore, agreed. Not the biggest fan on the IPlaceable approach though. Wonder if there would be some nicer way (I'll have to do some thinking on the matter). In new Tundra luckily we don't have this problem as Urho3D is the core dependency of that project. As a quick'n'dirty hack we could add suite of functions like float3 IRender::WorldPositionForPlaceable(ComponentPtr placeable) for retrieving placeable information within TundraCore. We could also quite easily add Transform Entity::Transform(), but Transform in it's current state doesn't hold enough information (parenting biz) to be usable at all times. Edit: now that thinking more, we could naturally have also WorldTransform() and sniff if the entity is parented and perform necessary computations if possible within Entity class itself.

[Stinkfist0]

Related to #780