Clarify and fix inconsistent network_index behavior

### Context & versions
cardano-rosetta-java 1.3.x - Construction API endpoints
**NOTE: Tested and confirmed rosetta-ts has the SAME behavior**

### Problem
The `network_index` field behavior is inconsistent and poorly understood:
- Rosetta docs say it's for "identifying which UTXO was used" (probably like Bitcoin's vin/vout position)
- Data endpoints: only outputs have it
- Construction: only preserves it for inputs
- This reversed behavior between endpoints is suspicious

Need clarity on what network_index represents in Cardano context.
### Current behavior
Testing shows inconsistent handling:

1. `/construction/payloads` ACCEPTS network_index in operation_identifier:
```json
// Request accepted:
{
"operation_identifier": {"index": 0, "network_index": 0},
"type": "input",
...
}
```

2. `/construction/parse` RETURNS network_index for inputs but NOT for outputs:
```json
// Response:
{
"operations": [
{
"operation_identifier": {"index": 0, "network_index": 0}, // ✅ Input has it
"type": "input",
...
},
{
"operation_identifier": {"index": 1}, // ❌ Output missing network_index
"type": "output",
...
}
]
}
```

**ALSO in Data Endpoints** (tested /search/transactions, /block):
- Inputs: NO network_index
- Outputs: YES network_index (e.g., `"network_index": 0`, `"network_index": 1`)

### Expected behavior
Construction endpoints should consistently handle `network_index`:
- Allow users to specify network_index in `/construction/payloads` to control ordering of inputs/outputs in the transaction body
- Return network_index consistently for both inputs AND outputs in `/construction/parse`

### Why this matters
- While `coin_identifier` can't be known for outputs until the transaction is finalized (needs tx hash), `network_index` CAN be set in advance during construction

### Possible interpretations
`network_index` could be:
- For inputs: position in transaction's `body.inputs[]` array (equivalent to Bitcoin's vin index)
- For outputs: position in transaction's `body.outputs[]` array (equivalent to Bitcoin's vout index)

### Tasks
- [ ] Research what network_index actually represents (check other Rosetta implementations)
- [ ] Fix data endpoints to include network_index for inputs (currently missing)
- [ ] Fix construction/parse to preserve network_index for outputs (currently only preserves for inputs)
- [ ] Ensure consistent behavior: both inputs and outputs should have network_index
- [ ] Once understood, document clearly what network_index represents
- [ ] Add tests to verify network_index behaves consistently