orders: add position management commands and overlay

[Robuske]

Summary

Adds direct manager-order position management to orders:

• orders positions [--show-id] lists fort-wide manager orders in displayed priority order.
• orders move <current-position> <new-position> [--show-id] moves the existing order pointer within world.manager_orders.all.
• orders.position adds inline position fields to the Work Orders screen and uses the same move logic as the command.
• Shares Work Orders list geometry between the existing search overlay and the new position overlay.
  • The existing search result indicator was moved a bit to avoid overlap (see second screenshot).
• Adds documentation, a Future changelog entry, and contributor metadata.

The native orders plugin dispatches the new subcommands to Lua. Expected validation failures are returned normally, avoiding the extra Failed Lua call message.

Testing

• Built the orders plugin with the DFHack Visual Studio build.

• Ran:

  test -d C:/Users/rodbu/Developer/Dwarf/dfhack/test -t orders
  

  Result: 18/18 tests passed, 227/227 checks passed.

• Performed in-game testing of command moves, validation errors, inline editing, cancellation, focus handling, scrolling, and search-overlay interaction.

Normal	Editing + Search result indicator

Documentation

Includes orders command and orders.position overlay documentation, plus the required docs/changelog.txt entry.

[chdoc]

Before I spend a lot of time reviewing the code in detail, let me first ask a few high-level questions and make a few high-level comments:

1. What is the motivation for this change? I have never actually felt the need to reorder work orders. The only reason I can see to reorder work orders is to avoid low frequency work orders being starved by high frequency work orders. That is the purpose of orders sort.
2. Assuming I can be convinced that this has general utility, the described workflow of selecting a work order and then entering a number where it should be placed it does not sound appealing. If I wanted to sort orders, I would appreciate label buttons to move the selected order (we can select orders) one up, one down, to the top, or to the bottom. Has this been considered?
3. I cannot see a small UI/UX improvement like this requiring a change of roughly 900 additional lines plus another roughly 400 lines of tests. This seems over-engineered and gives me strong AI code vibes. Please give me a description in your own words (that is without the use of AI) of the general idea behind the implementation and why you think that this cannot be achieved using a smaller, more focused change.
4. In fact, some of the changes look like you are refactoring the tool at the same time as you are changing features. Please keep refactoring pull requests and feature pull requests separate. Is just because it caught my eye: Replacing self.subviews.filter with self.subviews.[SEARCH_FILTER_VIEW_ID] is an absolute no go, because it reduces readability for no gain whatsoever.