The core cause of your frustration with the situation is probably one of perception and misleading/wrong terms used by the customer. The customer does not usually come to you with a list of requirements, but a wish-list of every single thing they could think of that might be useful to them. Those are not all requirements because the customer hasn't spent the time yet to really think if each feature is truly required.
This is not necessarily always a problem
If your customer has the money for all those features and is willing to part with it, and you don't really care about solving the actual, real issues that the customer has, then this could be a very lucrative project. It happens, just very, very rarely, and for most developers it's soul-killing work because you can feel in advance that the project will not be successful for the customer in the end (even if it's financially successful for you as a developer). It's also high-risk because you're likely to end up with a fixed-cost project with a lot of uncertainty, and it's really issue to misjudge risk on large projects.
What if it is a problem?
Lets assume you're not in that rare situation. In this case you will want to address the two main shortcomings of the wish-list as given:
- It's unlikely that the customer has a correct idea of the costs of developing such a large list of requirements, so you're unlikely to get the contract for the amount of money you actually need to do it.
- It's unlikely that this wish-list accurately and succinctly describes the real problem that the customer has and wants to solve.
In my experience you need to address 2 to fix 1. Drilling down to the actual problem means that you, the developer, now have the necessary input to make creative leaps in solving the problem in ways that the customer themselves never even thought of. These solutions are likely to be much cheaper and quicker than the implementation of the full wish-list.
How do you fix that?
Like Matthew Flynn says in his answer - start by making the customer prioritize the requirements. This is not always easy, but force them to do it. If necessary use the phrase "If someone held a gun to your head, which single requirement would you keep?".
You will often find during this process that the customer really doesn't have a very clear idea of what the individual requirements mean. In that case do what Peter Rowell suggests and get the customer to work through User Stories. You and the customer will start to understand the problem and requirements much better, and then you can back to prioritization. Repeat those steps as often as you need to until you feel comfortable that you know enough to solve the customer's problem.
How does that answer the question of developing a solution?
Once you have a prioritized list of requirements, you have the input you need to suggest an incremental development process to your customer.
You don't have to call it Agile, but you can suggest to break down the contract into smaller pieces for each requirement (or indivisible set of requirements) and deliver them one by one with validation by the customer.
Or you can go all-out and use the many resources available online and offline to convince the customer that it's in their best interest to cooperate in one of the Agile styles of development.
In any case, you can provide your contract/project proposal in a form that clearly suggests these building blocks of requirements in priority order, each with their own cost and conclusion. Hold that carrot in front of the customer, and they may even think it was their own idea to decide whether to continue after increment :).