The service facade is the way to go -- it will make it much easier to managed and test in the long term. You can build the service facade as an entirely separate library in fact so you can use the facade in other apps without much to do.
Insofar as were to drop it, keep in mind that MVC is really a UI pattern, what happens below the waterline is really beyond it's concern. So have your controllers reference the service facade and pull out models to send to the UI and don't get hung up on what is a model vs what is a controller.
I think you got Fowler wrong, he is advocating 3, not 1 (see http://www.martinfowler.com/bliki/AnemicDomainModel.html). Note that he is not talking about "business logic inside entity classes", he is talking about "business logic inside domain classes". And Service objects are domain objects.
In your example above: if you need to calculate the orders total, why not create a service class "OrderTotalCalculator"? Name the class accordingly for its purpose (and not OrderService or OrderManager, which would actually hide the purpose).
You already mentioned one criteria by yourself for when to introduce such a service class, and when business logic can stick inside entities: when "a bunch of other classes" is involved, then placing the logic in a specific entity is probably not the best design. You also mentioned the single-responsibility principle, so let yourself guide by this.
However, this does not necessarily lead to option 2 - since to my experience there are typically enough business operations for which an entity can take the full responsibility for itself, without introducing an extra service class for every operation. This will typically lead to a lean (but not anemic) entity classes.
The third option is probably the right one, but it is also devoid of any useful info.
Yes, it is probably the right one, but what do you mean by "is devoid of any useful info"? Do you miss an instructions manual on this? Software development is a design process, not like working at an assembly line. So making the right design decisions is not always easy and needs a lot of experience. And naming things is actually one of the hardest tasks.
Best Answer
In 'SOLID' the 'I' stands for Interface Segregation. The whole idea of this principle is to split large interfaces into smaller ones, more modular. In MVC service would normally have an interface that controller would rely upon. You don't want your controllers to know about concrete implementation of that service. Therefore, a bunch of services with one or two methods is a good thing to have.
Services normally return DTOs in large applications or domain models directly in smaller applications. DTOs normally means more work, but better separation of concerns. The typical flow is:
Mapping can be done manually, but most developers prefer to use auto mapping framework such as Automapper because we don't like writing plumbing code and we can be quite lazy :-)
http://en.wikipedia.org/wiki/Interface_segregation_principle
https://github.com/AutoMapper/AutoMapper
One of many discussions on stackoverflow regarding use of DTOs and domain models: https://stackoverflow.com/questions/2680071/dto-or-domain-model-object-in-the-view-layer