Introducing API

Right now there's a lot of messy code in controllers. Furthermore, there
is no way to interact with szurubooru via vanilla HTTP, since API is
next to non-existent. So, basing upon my experiences from another
project, I plan to:

- Create actual API. It is going to consist of well-defined "jobs" that
  do things currently done by controllers. Benefits of such approach are
  as follows:
  - defining them in their own classes allows to clean up code a lot,
  - it allows to abstract from input method (POST data, part of URL,
	whatever), and leave processing of these to controllers,
  - it allows to make proxy controller, whose purpose would be to let
	users interact with API (jobs) directly in well-documented and
	consistent way.
- Make controllers responsible only for mediating between views and API.
  Behavior of these may remain inconsistent, since views they're talking
  to are also messy to begin with. Such controllers might be removed
  altogether in the future in favor of making views talk to API directly
  through previously mentioned ApiController.
- Organize all sorts of privilege checking and possibly other stuff into
  methods within jobs.
- Actually distinguish POST from GET requests.
- Leave POST-only controller methods as Actions, but rename GET-only
  methods to Views. Example: editAction for editing comments, but
  listView for showing comment list. The choice of these suffixes might
  be subject to changes in future.
- Get rid of ?json and $context->transport. They now look like disease
  to me.

This commit introduces job system and converts CommentController to use
the new API.
Changed default access rank from admin to none
Added subprivilege authentication
More robust argument handling
Moved comment removal to API
Moved comment listing to API
Moved post listing to API
Split login method into View and Action
Made logout redirect to last visted page
Renamed IndexController class and methods
Renamed LogController methods and moved to API
Moved tag toggling to API
Moved JobArgs to Jobs

Reason: trying to make unique string for every possible argument in
global fashion is difficult. For example it would make sense for
EditPostRelationsJob to accept argument named "post-ids", but it
wouldn't make much sense for AddPostJob to accept "post-ids" since it
doesn't tell much. Thus, common arguments are going to be defined in
top-level AbstractJob for ease of control, while more job-specific
arguments are going to be specified in respective job implementations.
Moved post upload to API
Moved post editing to API
Moved post flagging to API
Moved post un/hiding to API
Moved post removal to API
Moved post (un)favoriting to API
Moved post scoring to API