Don't move clients on ConfigureRequests (FS#1030)

I never saw a single program that set a border on its own windows. However,
awesome commonly sets borders on its clients and the position of a client is the
part outside of the border. So when processing a position request from a client,
we also have to include this border and fix things up correspondingly.

However, the same isn't needed for the client size, because the size does not
include the borders, but just the titlebar plus the "real" client content.

Thanks to Daniel Hahler for providing a simple test case based on urxvt for
debugging this!

Signed-off-by: Uli Schlachter <psychon@znc.in>
drawable/drawin: Pass both lua_State and stack index around

A stack index without the corresponding lua_State pointer is useless, because it
could reference another coroutine than the main thread and thus just assuming
globalconf.L is wrong. Fix this by also passing around the corresponding
lua_State pointer.

This improves the result for the following test:

  coroutine.resume(coroutine.create(function()
      drawin({}).visible = true
  end))

Signed-off-by: Uli Schlachter <psychon@znc.in>
drawin: Use the correct lua_State for the stack index

This just pushed the drawin onto the stack L, but then tries to access it via
globalconf.L. This just calls for problems...

Signed-off-by: Uli Schlachter <psychon@znc.in>
Fix some more dubious uses of globalconf.L

Signed-off-by: Uli Schlachter <psychon@znc.in>
tag_client: Add explicit lua_State argument

tag_client() said that it refers to the tag ontop of the lua stack. However, it
implicitly used globalconf.L as its stack. So if you tagged a client with a tag
from a coroutine, thinks would Go Wrong (tm). Fix this by adding an explicit
lua_State* argument.

Signed-off-by: Uli Schlachter <psychon@znc.in>
Merge branch 'master' of https://github.com/awesomeWM/awesome into local