Refactor the logic of placing client-menu with ShowMenu action

Refactor the logic of placing client-menu with ShowMenu action

Before this commit, we assumed `ShowMenu` action is not bound to any
buttons other than window menu button and always place the client-menu
under the window-menu button when atCursor="no". Also, it was going to be
difficult to distinguish whether the action is executed from the window
menu button or the window icon, which will be added soon.

This commit fixes it to open the menu under the actually-clicked button by
passing `cursor_context` to `actions_run()`, with some refactoring:
- `seat->pressed.resize_edges` is removed and it's calculated from the
  cursor position and `seat->pressed.type` just before running Resize
  action. This slightly changes the existing logic to determine the
  resizing edges with Alt-Right + Drag mousebinding, but
  `seat->pressed.type` is still stored on button press so it doesn't bring
  back the issue #543.
- `seat->pressed.toplevel` is removed and `get_toplevel()` in
  `update_pressed_surface()` may be called more often, but its overhead
  will be negligible.