Of course, none of this is set in stone. Different organisations do things differently. I can tell you my reasoning for categorising things the way I do, but I don't think there is any meaning to having a canonical system.
First lead developer. To me a lead developer is the person on a team that leads the technical direction of the team. Programming is all about judgement calls and long term success on the technical side depends on getting those judgement calls right more often than wrong. Some lead developers like to make all technical decisions, but this can create a bottle neck and also piss off the rest of the team. For those reasons, I don't like that approach and prefer to have the lead developer act as a technical coach, leading by example. The lead developer should have the final say on technical decisions and should be aware of all of the decisions being made on the team, but they should avoid making decisions if they can. On political matters, they should refrain from being too active, but rather defer to the development/engineering manager if there are any problems. Lead developers should also write a lot of code IMHO.
The sound clip is, though, the lead developer should be a 10x developer by virtue of doubling everybody else's productivity. However they do that is fine.
I tend to use the term "development manager" rather than "engineering manager" for arbitrary reasons, but they mean the same to me. A development manager ideally should make no technical decisions. That should be left to the lead developer. In some organisations, the team is not deep enough to have an effective lead developer, so sometimes the development manager has to take on that role too. In other organisations, there is no development manager and so the lead developer has to take on that role. It's not optimal, but it really depends on the size and depth of the organisation.
A development manager's responsibility is political in nature. First they must evaluate and track the progress of the members of the team (usually working closely with the lead developer to get insight). They will ideally decide on the head count of the team, choose the members of the team, organise hiring if necessary and arranging for movement out of the team (whether that is a transfer or dismissal) if necessary. The development manager is responsible for the conduct of the team. If there are behavior problems, the development manager must find a solution (usually working with the lead developer) to those problems. The development manager is responsible for tracking performance of developers, negotiating raises, managing career progression, finding appropriate training, allocating resources (for example computers, desks, chairs, internet), etc. They are also responsible for ensuring that outside problems are dealt with effectively. A big part of that is making decisions about how to deal with external requests for development, allocating people to deal with problems, etc, etc. They must work with the project manager(s) to track performance and ensure that there are adequate people available to do the work that is necessary. The must work together to track work completion and adjust expectations for delivery dates, etc.
Where the lead developer is looking at the tactical view about how to best accomplish a series of tasks, the development manager is looking at the strategic view of plotting the current location and direction of the team (as well as dealing with the people problems and political fall out from that).
I wrote earlier about what I see the project/product manager doing, so I won't get into it too much, however I'll talk a little bit more about the communication/politics role the product/project manager needs to do. Unless the company is small, there are usually a lot of other departments, many of which dwarf the IT group. These groups include (but are not limited to) marketing, sales, documentation, customer service, etc. In some organisation you even have a separate IT group from development usually called "services" that does custom development for large customers. The project manager has to coordinate all of these groups. This is a big job. They need to listen to all of these groups to gather requirements. They need to coordinate with marketing and sales to keep them synchronised for timing. They have to constantly update everybody as business needs and requirements change. They need to make sure that marketing aren't putting together a campaign for something that you aren't building. They need to stop sales from selling things that you don't have. They need to coordinate the development of documentation. In some industries they need to arrange for and plan certification. I could literally type for pages on this kind of thing. You need at least one person dedicated to this job for each project in most large companies.
The main difference between a project/product manager and a development manager is that one if focused on the project/product and one is focused on the performance of the team. You can merge these roles in a small company, but there are desirable separations of concerns in these roles. Especially (and it's a bit hard to say this politely), there is plenty of latitude for abuse if both of these roles is performed by the same person.
You will notice that I haven't answered your first question. I don't make a distinction between project and product managers. However, many people do. I think the best way to look at the situation, though, is that you almost always need someone who is responsible for the artefact that you are building. They "own" the requirements for that thing. I will say that just like the lead developer position, I prefer a technique where as "owner" you don't actually make all the decisions. Instead you are aware of all the decisions and you make the final decision when there are problems. It's the ownership of the responsibility, really, rather than the ownership of each individual choice. Otherwise you get into the same position of becoming a bottle neck, or pissing off the rest of the team who has to pay for your mistakes, even though they have no say in the matter. It's a hard job, though, because you really have to travel around talking to people all day and make sure that you understand every decision being made.
On the other hand, just like there is a separation of tactical and strategic goals in development, you can do the same in the project management side. So you can have a project/product "owner" and a project/project manager, who may be responsible for the strategic view of how all these tings are fitting together. In a very large company, you almost certainly need this role. Most of my career has been spent in organisations with less than 200 developers and in those organisations, I've never really seen the need. YMMV.
Edited to fit into a reply (apparently I typed too much).