fix the bug on the leading time schedule

[TheLovesOfLadyPurple]

What does this PR do?

When the current UniPC Multistep Scheduler call the set_timesteps, it would not generate the correct leading time schedule. To be more explicitly, if you input different num_inference_steps when you call this function, it will generate different first timestep at the beginning of the inference. However, user will expect the first step is fixed on 999.

Fixes # input different num_inference_steps to the set_timesteps of the UniPC scheduler would generated different start time step.

We fix this bug on the UniPC Multistep Scheduler. Now the first inference step is fixed to 999. We write a simple test code and ensure that the first step of the inference is correct.

Who can review?

@yiyixuxu

[TheLovesOfLadyPurple]

If necessary, you can also add a breakpoint on line 1031 in the file src/diffusers/pipelines/stable_diffusion/pipeline_stable_diffusion.py to check it. It's actually very possible that other multi-step solver also has such a problem.