Make re-ordering stations easier

**Describe the task**
We could make insertion/deletion/re-ordering of stations in Planning Area lists easier if we stopped using a sequential 1,2,3,... approach and instead used order values (for the stations that are already in our DB) in multiples of 10. It should order stations on the frontend in the same way as before, because we're just sorting by increasing `order_of_appearance` value, without any implicit expectation that the values are sequential.

Then when we want to add a new station to a Planning Area list, we don't have to reassign ordering for all the other stations.

Example:
Current Approach:
Station | Order_of_appearance
A. | 1
B. | 2
C. | 3
D. | 4

To insert Station E in position 2, we then have update the ordering of stations B, C, and D when we insert E. Tedious.

Alternative:
Station | Order_of_appearance
A. | 10
B. | 20
C. | 30
D. | 40

To insert Station E in the second position, we'd just set Station E's order_of_appearance to 15.

**Acceptance Criteria**
- [ ] In the `planning_weather_stations` table, each station's `order_of_appearance_in_planning_area_list` value should be a multiple of 10 (or 20, or 100 - whatever) to make space for other stations to be inserted into the list at a desired order without having to reorder all subsequent stations in that planning area list
- [ ] Ordering of stations should appear in HFI Calc table as before

**Additional context**
- Add any other context about the task here.
- Or here

Start by locating the planning_weather_stations table and the code that supplies station ordering to the HFI Calc table. Verify how order_of_appearance_in_planning_area_list is stored and sorted, then implement the spacing approach and confirm the HFI Calc display remains unchanged; the work is done when existing values have room for insertions without reordering subsequent stations.

Written by the indexing model from the issue text.