Use server side targeting

THis version now uses server side targeting for attacking. That way we
are prepared for using another "base" system than svo.
Don't print sends on the console
Detach from svo step 1: create strategy structure

We use a pattern that is very similar to the strategy pattern in OOP, which makes it very easy to switch the underlying system, even on the fly.

For that I created a structure that will hold system dependant code. For now all calls are hardwired to the svo "strategy".
Detach from svo step 2: Make used system variable

While we still use svo hardwired, this choice depends on a variable. This variable can become a configuration variable next, which can be assigned with failsafes and possibly autodetection.
Fix buggy use of server side targeting

We should now set the target correctly.

Also removed some unnecesary hardcoded target positions.
Merge branch 'SystemlessSupport' into UseServerSideTargeting

Conflicts:
	script.lua
Merge branch 'UseServerSideTargeting' into SystemlessSupport
Detach from svo step 3: Use wundersys as PoC

While own balance queueing still has ways to go, this version implements
rudimentary support for wundersys. That means, wundersys is now used by
hardcoding (configuration is not in yet) and does not support automatic fleeing
yet.

This version exists to test the viability of the base functionality under other
systems: prioritize the bashing targets
Use gmcp targeting

GMCP provides a clean interface and gives additional info about the target. We
can use that later on.
Merge branch 'UseServerSideTargeting' into SystemlessSupport

Conflicts:
	script.lua
Fix targeting/attacking for the systems
Add variable shielding support

It is now possible for systems to define their own shield handling.
Allow configuration of the underlying system

The basher tries to autodetect the system by characteristic tables. If no
out-of-the-box supported system is used, the user can configure the system with
an alias.
Idea for wundersys fleeing part I

Implement an idea for fleeing with wundersys: Trigger on the queuing message and try to estimate the damage we take within 2(!) cycles and take healing into account.

But since the regex for the queuin system is unfinished we want to [skip ci]
Idea for wundersys fleeing part II

This fixes the remaining issues with fleeing and wundersys as well as some
issues introduced when putting svo functions into their own table.

It also fixes some issues with certain gmcp tables, if they don't exist yet and
moves the system setup to the login function.
Merge branch 'master' into SystemlessSupport
Update README.md

Added information about things in development. [skip ci]
Minor improvements

- both supported systems: changes in the display (use the boxDisplay functions)
- both supported systems: allow for specifying the position of the target in the raze command.
- WunderSys: disable the queue trigger when not needed
Make warn and flee values more flexible

You may now specify a percentage of your max health (ending with a % sign) or a
multiple of the average damage taken in this room (ending with a "d") as warnat
and fleeat values.

Also some bugfixes
Fix flee value calculation from damage