Based on my knowledge, real "agile projects" don't really have exactly that kind of tools you are looking for, unfortunately. Items from 1 to 6 are covered with a backlog, iteration backlog and a psychical whiteboard. In most of the cases the backlog is a spreadsheet, or a collection of issues in JIRA or in redmine, or just a couple of post-its on a wall. Mike Cohn has several blog posts about backlogs. Here is one interesting.
Your list is great, but the agile approach is so different from the usual project management methodologies that it is hard to map the two. For example, "Managing Profit & Loss of projects" is handled a bit lightly in Agile: we continuously talk to the customer, and we don't commit to more than we can deliver. With this approach, the customer won't loose money over development and since we don't commit more we can do, we don't really loose anything.
Anyway, this is how I would do the mapping between your list and my view on Agile:
Reporting risks, impediments, sprint and release progress to POs/management
Possible risks are discussed during the planning meeting and during the daily stand-up meetings. If the PO sees a risk, he should immediately go to the customer and talk about it. Some POs put the risks into the backlog.
Defining project tasks and resource requirements
In Agile, the PO creates user stories based on customer requirements and tells these stories to the team. The user stories are kept in the backlog. After the team understood what needs to be done, it creates tasks and put them into their sprint backlog.
Writing project plans and scheduling project timelines
It is in a backlog. There is a possibility to have a release backlog, but not everybody agrees on this.
Tracking deliverables
The result of a sprint is visible in its sprint backlog as a done item. Unfortunately, the sprint backlog is usually destroyed after a successful sprint, because the customer got what she asked for, why keeping records? Fortunately, there is a change here. Teams started to store their tasks and user stories in an issue tracking system - like JIRA or redmine - and they create versions there, too. So you can see what was delivered and when. (We could have saved some money if we had something similar when I started with Scrum)
Reporting project progress, problems and solutions
There isn't much reporting. These items are discussed during the daily stand-up meeting.
Evaluating projects and assessing results
The product owner "reports" to the customer and provides feedback to the team during the retrospective about the recent sprint.
Managing Profit & Loss of projects
I mentioned this earlier.
