Rethink phase management

A contest can be in three phases: pre-contest, contest and post-contest. CWS, in addition, defines a user-related actual_phase which takes the contest.per_user_time and user.starting_time into consideration for USACO-like contests. So we have the following "actual" phases:

• phase -2: the contest has not started yet
• phase -1: the contest is running but the user has not started its per_user_time yet
• phase 0: the contest is running and the user can send submissions
• phase +1: the contest is running but the user has already finished its per_user_time
• phase +2: the contest has already finished

At the moment all phases except phase 0 are handled almost the same by CWS: the user can't do anything except reading the documentation, view announcements and messages and ask questions (and read answers). On phase -1 there's a small difference: the user can start his/hers per_user_time.
On phase 0 the user can do almost anything: read statements, download attachments, send submissions and usertests, use tokens, etc. (but not start his/her per_user_time).

We may want to change this behavior (at least partially). For example we may want to give a user access to his/her submissions even on phases > 0, to allow to see the results of last-minute submissions which may get fully evaluated only after the contest ends (of course we would continue to block new submissions). Also, it could make sense to allow to use tokens even after the contest.
We should also decide if we want to implement the analysis mode properly, or if we think it's enough to do as we did at the IOI (extend the contest length and give infinite tokens).

This issue is the right place to discuss all of this.

No files, tests, or entry points are named. Start by locating the current contest and actual_phase handling, then review the proposed permissions for each phase and the analysis-mode alternatives. Done requires an agreed phase policy and a defined implementation scope; this issue is currently an open design discussion.