Should the Product Owner prioritize the backlog side-by-side with the customer?
Must this step be done during the Sprint Planning Meeting, or could it be done before the meeting?
Is the meeting restricted only to the Product Owner and the Team?
There are plenty of ways to prioritise the backlog.
Firstly, the customer is not always the product owner - the product owner might be representing a number of stakeholders including multiple customers, or people with a longer term view. The product owner really needs to understand all needs and come up with the best way of prioritising.
So then, first and foremost the first rule should be: do what is most important/highest impact first. In real terms as there is always too much work to do, I ask the golden question "does this really need to happen or can it wait". Make sure there is a real objective to every requirement - don't get fooled into thinking something is important unless it can be justified.
The next thing is to think about risk - make sure you have a balanced portfolio of items - things you know are low risk and therefore are going to be done plus a few high risk items (which are probably some of the most important) that you want to get done. Do not have a release full of high risk items for obvious reasons (risk being defined as things which include unknowns/technical or logistical challenges).
Finally, you can do things like quantify the value or impact of work. There are some good books on Agile Estimating and Planning - see Part 3 of Mike Cohn's book on planning for desirability http://www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning
There is no single universal way of prioritizing backlog. Much depends on the way team works and on the customer, e.g. how often they change requirements.
Generally the closer you follow standard (by-the-book) model, the closer you will be to the following solution:
High-level prioritization on coarse-grained features is done at the beginning of the project. It is often done when discussing with the customer which features are must-haves and which are nice-to-haves. It should be done with customer if possible. Otherwise you'd be guessing what is really important and what isn't.
Then before every sprint remaining backlog should be prioritized on fine-grain level. It doesn't really matter whether PO makes it just before the sprint or during the previous one. The important thing is that the team should know their priorities for the next iteration. Ideally this prioritization is done with the customer but when general plan is approved by the customer and it doesn't change much Product Owner can make their own calls basing on their knowledge.
If you work in environment where requirements are changing very rapidly you may consider constant re-prioritization which is basically what happens when you deal with Kanban backlog. In this case PO prioritizes features every time when anything changes.
The Product Owner and the Customer should be the same person. The project manager should be the person going through the detail, working out resource allocation and tracking progress (using whatever tools are available). The Product Owner is the person responsible for a.) describing at a high level what the requirements are, and b.) prioritising the list of features that come of the list of requirements.
Typically a list of features (/requirements) is scoped at a high-level by the team, which gives everyone a view of how expensive (in time / $$$) any given feature is. This is essential if the PO is to prioritise development (if something is very costly to develop it may be pushed down the priority list).
As features reach the top of the priority list they are broken down into more and more detail, until by the time a sprint starts each feature is described and estimated at a task level by the person responsible for its delivery (i.e. a developer, and not a project manager).
We use Fogbugz, and go through a process of breaking Features down into tasks which are then estimated. The backlog is then prioritised by Feature (not task), and the estimate for any Feature is the sum of all the child task estimates.
Prioritisation should be a continuous process, although it helps if the focus of the team isn't shifted within any given iteration.
The product owner should represent the customer and their best interests. If you have the customer on your team too, great! Remember that the product owner is supposed to guide the project into the direction that most benefits the customer, while balancing corporate interests (limited resources, time, etc.)
This should ideally be done sufficiently before the sprint planning meeting so that the team can take the highest-priority stories and start working. From this perspective, sprint planning is only for the team to choose how to fit as many of the top-priority stories they can into the sprint, in the priority order.
The other two answers (@pawelbrodzinski, @Hugo Rodger-Brown) represent two other approaches -- splitting off at a coarse-grained level, and splitting off by feature. Whatever works for your team is what you should do. (I disagree with prioritizing by feature, since you often want "just enough" of more than one feature done within a single sprint.)