I'm assuming that you have worked with your team to generate estimates for how long it will take to produce each deliverable. I'm further assuming that they have given you a most-likely case scenario and a worst case estimates for each.
Take the most-likely case scenario and create your schedule. Review this with your team against the master resource schedule and confirm that you have the team available to achieve this schedule. If enough of the team is NOT available you wll have to adjust your schedule to account for this, or get team members taken off of other projects in favour of your project, or introduce into your plan activities around getting new hires and training them up.
Once you have your most-likely case schedule aligned to team availability do the same thing for your worst-case scenario. The purpose of doing this is to allow you to report to your sponsors a range of dates for project completion. This will really help you in the long run in terms of managing expectations.
Finally, run the schedule past your team and get their buy-in. Document that they agree that the schedule is reasonable and achievable, ideally getting them to formally sign-off. Distribute the schedule and off you go.
In response to your specific options:
1.Schedule all tasks "as late as possible" leaving the entire float at the front end of the project. This would assume infinite resources.
Probably not a good idea because people will tend to put things off to the last possible moment. Also bad things tend to happen at the last moment. Using "as late as possible" for scheduling poses a significant risk to the project by not allowing for late delivery.
And assuming infinite resources is a very bad assumption.
2.Schedule all tasks "as early as possible" leaving float at the back end of the project. Also assuming infinite resources.
Better than #1, but I would tend to associate buffer with particular deliverables so that when there are internal hand-offs the receiving team is aware that a range of dates is possible. For example, the development team should be aware that requirements gathering and documentation should be complete by date XX but could be delayed by as much as 5 days.
Again, assuming infinite resources is not good.
3.Schedule each new project according to a master resource schedule. This would mean that any future identical project would potentially have a different baseline than a previous one.
By definition a project is a unique undertaking. Even if it is "cookie cutter" you will have different baselines. For example, a project in the USA that takes 3 months to complete if I start in September will likely take longer if I start in November (people are away over the holiday season) or in June (summer holiday season).
I also don't see why you wouldn't consult your master resource schedule so that you are able to ensure your schedule is realistic and achievable.
4.Some hybrid of #1 and #2 with float distributed somewhat evenly prior to significant milestones in the workscope.
This is more what I typically do, see comments under your option #2