How to represent product backlog planning in the project plan?

Consider this quote from the Scrum Guide:

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Trying to create a plan that encompasses "all Sprints" is not Scrum, or any other form of Agile. Agile methods tend to be build around creating and maintaining products and services, not projects.

It is possible to define a plan for efforts that use Scrum, but you need to remember that you can define the activities and how they are sequenced, but that they will repeat until the stakeholders no longer find value in proceeding or your continuous improvement activities result in a change to the activities.

All of the traditional activities fit within each Sprint. Discovery is the Product Owner's management of the Product Backlog and the team's refinement activities. Planning is Sprint Planning. Design, build, integration, test happen within the Sprint.

I am asked to prepare project plan that follows the scrum methodologies with all sprints in it.

Who has asked you to do this, and what benefit is Scrum expected to bring in your situation?

Should I show all sprints after the phase of requirement gathering is completed. This phase of requirement gathering may go on for months.

Scrum knows no phases, nor are you being Agile by gathering requirements for months. My best advice is to get started as soon as possible. Most Scrum teams only need one Sprint's worth of Product Backlog to get going.

In Scrum your Product Backlog emerges over time, as your Product Owner learns more as he or she sees the product being built and uses and from customers on how the product is being used.

It's likely that your organization wants to do great things like truly agile organizations have done, and still do, but they're really driven by a PMO and are and will always be waterfall. In a case like that, you do the best you can with your knowledge of Scrum and apply it to the world you're in. The sprints can be as short as you want. I like one week sprints. And your Product Backlog Items are your requirements. 

When you do the offering in Scrum, you normally say something like "with the knowledge we have today, we will do this in x sprints of y weeks" and with that you can give a ballpark figure. If you have something like that at hand, I would build the Project Plan the same way. Just put the Sprints in.

And on another page, try to explain the organization what SCRUM is about and that with SCRUM you do not plan the whole project, but smaller chunks and that in Agile Development things can change.

Implementing Scrum the difficulty is not really to implement it in the Scrum Team, the huge difficulty is to implement it in your organization and with your customer.

Thank you everyone for your responses. The responses were useful in understanding the thought process behind Scrum planning. 

However; the challenge I face, is how do we provide efforts and cost estimate for a project whose activities are not defined, and thus not clearly estimated. How do we provide a schedule or completion dates? These questions may be very rookie, but it is difficult to tell to the customer or bosses that we don't have a accurate timeline for now, but will be in a better position to give you rough estimate after some sprints. 

However; the challenge I face, is how do we provide efforts and cost estimate for a project whose activities are not defined, and thus not clearly estimated. How do we provide a schedule or completion dates?

You don't.

The agile methods, including Scrum, are designed to be used in efforts with ambiguity and uncertainty. The techniques used are designed to allow teams to adapt quickly to learning new information and using that to deliver higher quality products and services. When you have this level of uncertainty, it's not feasible to identify the activities and scope of work in a way that lets you give any kind of reasonable up-front estimate of time or cost.

Instead, consider what is fixed. The team composition is usually fixed for an extended period of time. The length of an iteration is often stable. With these two pieces of information, you can calculate a cost per iteration. You can start by funding a reasonable number of iterations and the team will deliver valuable software at the end of each iteration. Each iteration would add clarity into exactly what is necessary and the team would be able to forecast when the known set of work is likely to be completed over time.

This approach also has an advantage. Most contracts have change control built in to handle changes in schedule, scope, and cost. However, change control is built into iterative and incremental efforts - either side can suspend or terminate work when another iteration would cost more than the value that would be introduced.