input_throttle_calc() uses Betaflight throttle curve

This PR changes the throttle curve calculation to match Betaflight's. ### Quicksilver's Throttle Curve Currently in Quicksilver, throttle mid shifts the curve so that Y=mid when X=0.5. All of these graphs use **mid=0.38** and **expo=0.85** (no special meaning; just happens to be current settings): <img width="629" alt="Screenshot 2025-01-12 at 08 35 24" src="https://github.com/user-attachments/assets/89447c26-4fd8-43fa-a736-618420907e05" /> However, Quicksilver's math means that the throttle curve no longer reaches 100%: <img width="631" alt="Screenshot 2025-01-12 at 09 10 13" src="https://github.com/user-attachments/assets/c681d3b4-dee4-4ded-a962-a637dd38006c" /> This is even more pronounced with lower midpoints. A throttle mid of 0.25 results in a maximum throttle output of 50%: <img width="609" alt="Screenshot 2025-01-12 at 09 11 37" src="https://github.com/user-attachments/assets/40e4bb5e-3d4f-4ae5-8ec2-d28aea145300" /> ### Betaflight Throttle Curve "Mid" is probably a confusing name for Betaflight's implementation. It's made worse by this setting lacking a ? tooltip in their configurator, along with somewhat muddy community explanations over the years. In Betaflight's throttle curve, mid is _where_ the expo is applied. It's more like the center pivot point where throttle input equals throttle output. The same **mid=0.38** and **expo=0.85** values: <img width="619" alt="Screenshot 2025-01-12 at 09 16 49" src="https://github.com/user-attachments/assets/7414f86c-7e09-4aa9-aabf-66c1badbb160" /> Stick midpoint no longer has any special meaning, and will depend on curve settings: <img width="624" alt="Screenshot 2025-01-12 at 09 16 57" src="https://github.com/user-attachments/assets/a63a4521-b60e-49eb-aabe-989c66a4e3d9" /> Crucially, 100% input always results in 100% throttle: <img width="615" alt="Screenshot 2025-01-12 at 09 17 04" src="https://github.com/user-attachments/assets/84fafb52-64cf-4084-a633-5e7a30e55759" /> In Betaflight's throttle curve, mid has no effect if expo is 0. ### Existing Implementation Mid > 0.5 Values I do not have any heavy-enough whoops to require a >0.5 values for throttle mid, but it's worth pointing out that the throttle clips. Here is **mid=0.8** on existing Quicksilver: <img width="619" alt="Screenshot 2025-01-12 at 09 19 03" src="https://github.com/user-attachments/assets/a081dfc6-e35a-4a53-b659-7c777703954a" /> ### Motivation and Ramifications For my use case, I am flying a 1S whoop where I am unable to give up any throttle headroom in my motor settings. I began investigating the throttle curve math in Quicksilver to see if I could work around the lowered throttle ceiling issue with some other settings. I don't see how I can, hence the code change. For pilots that may be using larger craft with a motor limit already in place, they should be able to adjust their motor limit to compensate by raising their motor limit whenever they adjust their throttle curve. Transmitters can also set throttle curves, although I do tend to tweak my curves per-quadcopter based on slight weight differences, which means I would need a different radio model per quad. I don't have a clear idea of whether racers (or some other subset?) very specifically want this sort of "make stick midpoint map to different position on throttle curve" implementation that Quicksilver has now. Maybe? Although throttle curve clipping at mid values >0.5 and maximum throttle loss at <0.5 values seems like a poor tradeoff. Merging this behavior will result in a different throttle curve for existing profiles with non-default mid/expo throttle curve values. At minimum this might require some adjustment (regardless of whether that pilot realized the curve limitations described above), or worse will remove the ability to remap their throttle in this different way. My personal opinion is that the vast majority of people will expect Betaflight's throttle behavior. But there are other possibilities for implementing this PR: * Allow user to choose a throttle curve mode, similar to rate calculation modes * Keep existing math, but somehow lerp/blend so that 100% input still results in 100% output. At least for me, truncating max throttle output is a no-go on my 1S setups and is the thing I care most about here (using Betaflight's curve is just one way to achieve this easily)