Dynamically configured flight profiles

[EdHurtig]

Currently, all flight profiles are configured by #defines in core/config_inventory.h. This data should be packaged into a struct flight_profile like so

typedef struct flight_profile {
    useconds_t watchdog_timer; // Main braking timeout initiated by pushing state // 5MPH 4300000
    useconds_t emergency_hold; // time held in the emergency state
    useconds_t braking_wait; // Time before engaging secondary brake, if needed
    useconds_t braking_hold; // min time to hold brakes before vent
    useconds_t pusher_timeout; // Timeout for the pusher plate debounce
    float pusher_state_accel_min; // m/s/s Threshold for transitioning into the pushing state
    useconds_t pusher_state_min_timer;  // Minimium time in the pushing state
    float pusher_distance_min; // mm Distance to register the pusher as present
    float primary_braking_accel_min; // m/s/s min acceptable acceleration while braking
} flight_profile_t;

A command should be defined in core/commands.c to accept and parse a flight profile given by a remote controller and the flight profile should be stored in the global pod structure (use pod_t *pod = get_pod();)

Configuration of a flight profile should only be allowed in Boot state and you shouldn't be allowed to proceed out of Boot without a valid flight profile being given to the vehicle.

Web UI support is needed to create a form with all these parameters and the associate JS code to make an AJAX call to the command proxy endpoint in ODS