Keep a bill's category and payment mode when it is updated

[Pascal-SAPUI5]

Editing any bill in a Cospend project silently moved it to "uncategorised" and
reset its payment mode on the server.

Cause

Two things combined.

Bill never decoded categoryid or paymentmode, so both values were dropped
the moment a bill arrived from the server. paramsFor(_:) then hardcoded
"categoryid": "0" and "paymentmode": "n" into every request.

Changing only a bill's amount was therefore enough to destroy its category, and
Cospend's own category statistics degraded a little with every edit made from
the app.

Fix

Both fields are now decoded and round-tripped, falling back to the documented
Cospend defaults (0 / "n") for a bill that genuinely has none.
BillDetailViewModel.createBill() carries them across the edit form, which has
no field for either — so a bill keeps whatever it was given in the Cospend web
UI even when edited here.

iHateMoney is unaffected: it has no such concepts, and neither key is sent on
that path.

Changes

• PayForMe/Model/Bill.swift — decode categoryid / paymentmode, stop
  hardcoding them in paramsFor(_:)
• PayForMe/Views/BillDetail/BillDetailViewModel.swift — carry both values
  through the edit form
• PayForMeTests/BillCategoryPreservationTests.swift — new

Verifying

Six tests in BillCategoryPreservationTests cover the round trip end to end:

• testCategoryAndPaymentModeAreDecoded — both fields survive decoding
• testPayloadWithoutTheFieldsStillDecodes — an older payload lacking them
  still decodes
• testParamsPreserveCategoryAndPaymentMode — the request carries them back
• testParamsFallBackToCospendDefaults — a bill with neither gets 0 / "n"
• testIHateMoneyParamsCarryNeitherField — iHateMoney requests stay unchanged
• testEditingABillKeepsItsCategory — the regression itself, through the edit
  path

By hand: in a Cospend project, give a bill a category and a payment mode in the
web UI, then change only its amount in the app. Before this change the bill came
back uncategorised with the payment mode reset; now both survive.

The change to project.pbxproj is only the registration of the new test file.

Relation to #42

This is the bug underneath #42, not the feature itself. #42 asks for pickers to
choose a category and payment method when creating a bill; this PR makes those
values survive at all. As things stand, Bill discards them on decode and
paramsFor(_:) overwrites them on every request — so a picker built on top would
have nothing to read and nothing to write to.

The logic here is deliberately independent of the UI, following
@InteractionEngineer's note on that issue (29 July), and it touches only the
Cospend path — iHateMoney has no such concepts, as pointed out in the same
comment.

@magshee — you picked up #42 in July. This should give you the round trip to
build the pickers on, and nothing in it constrains how the UI ends up looking.
Happy to adjust or drop it if it gets in your way.

[magshee]

Hi!
Unfortunately I have been a little busy since I picked up #42 in July. I've been working on it since then from time to time, but the solution was not as straightforward as I hoped it would be.

On first sight, your solution to a subproblem of ticket #42 is similar, or eventually the same to how I solved this. One difference that I noticed, is that paymentmode is a String in your solution. I used and Int here, as this is also what the latest swagger documentation of cospend says.

Would you be so kind explain to me, why you chose to use a String there?

[Pascal-SAPUI5]

Good catch. I think we are looking at two different fields.

Cospend's OpenAPI spec has both of them. paymentmode is a string, the old single letter code like "n", "c" or "b". paymentmodeid is an integer and points at a user defined payment mode.

I kept paymentmode as a String because that is what the code was already sending. dict["paymentmode"] = "n" was hardcoded in paramsFor(_:) before this PR. I only added the round trip and left the type alone.

If you are working with paymentmodeid, then your Int is the right call, and that is the field you need for custom payment modes anyway. My change only stops the app from destroying what is already there. If your work covers that too, feel free to close this one.