That's a lot of questions, so we'll take it from the beginning.
1) There's actually no limit to the amount of labels you can put on a single packet. Typically you'll be limited by the MTU along the path, as each label adds 4 bytes to the total packet size. In my own "crazy" labs, I've tried to accumulate a huge label stack just for the fun of it - when I reached six labels, I decided to stop.
2) MPLS labels are pushed to the front of the packet, so the bottom label will be the VPN label (learned via MP-BGP VPNv4 address-family), while the topmost label will be the IGP/LDP label to the egress PE router.
3) Changing the order of the label stack is not something you'd want to do. It will break things. Most switches and routers perform label operations on the topmost label only by default, so if you for some reason had the VPN label as the topmost label, traffic would be switched to a wrong destination or simply dropped if there was no entry for that label value in the LFIB.
4) The source and destination addresses of the LDP session will be whatever the LDP router-id is configured to be. LDP performs neighbor discovery and thereby learns the router-id of its connected neighbors. LDP will use this address as the destination address when setting up the LDP session to that neighbor. Typically you use a loopback address for this purpose, and even more often you want to specify which interface to use to make sure it doesn't change all of a sudden.
Scenario 1: The order of the labels is swapped, if you have written the labels in the order they are added to the packet. Consider this simple example:
3003 is the VPN label and 2001 is LDP label. 3003 will have the bottom-of-stack bit set to indicate it is the last label.
Scenario 2: Same as scenario 1.
Scenario 3: Here I'm assuming that you are running a L2VPN or L3VPN service. If you are running strictly MPLS-TE without any LDP involved, the label order from top-to-bottom will be just as you've written: First TE label, then VPN label - identical to scenario 1 and 2. For the LDP label part, I'm not sure in which cases you'd actually have a LDP label when forwarding traffic down a TE tunnel. The small lab I've setup for this doesn't add a LDP label, even if I enable MPLS on the TE-tunnel itself.
Scenario 3 would require additional lab to completely determine if LDP will be added at all. I need some time to setup scenario 4 and 5 to verify if the label order is correct. As it's getting late here, I'll continue setting up the lab over the next days.