Handle different street/number orderings

Describe the bug

I've noticed that the parser has issues in some cases with addresses that it should be able to parse. Unfortunately I have a really hard time grokking this codebase, so forgive any unscientific descriptions of what I observe. But I think one of the issues is a sort of bias to <number> <street> ordering.

Steps to Reproduce

Try to parse Lehtmäe tn 18. For a quick repro, the compare tool works for this via autocomplete.

{
  "subject": "Lehtmäe tn 18",
  "street": "Lehtmäe tn 18"
}

If you flip the order around to put the house number first, this actually will parse successfully. It even knows about the Estonian street abbreviation. (Elsewhere, this is also not ordered correctly btw, but this report focuses on the parser.)

Expected behavior

Probably this:

{
  "subject": "Lehtmäe tn 18",
  "housenumber": "18",
  "street": "Lehtmäe tn"
}

Environment (please complete the following information):

Probably N/A; reproducible on my Mac locally, on Linux servers using the official images, etc.

Start with the parser behavior exercised by the compare tool's autocomplete request for Lehtmäe tn 18, then compare it with the working house-number-first ordering. Reproduce the issue and make the parser return housenumber: "18" and street: "Lehtmäe tn" while preserving the subject.