Adding location_index field in output where the location field is present

[krashish8]

The location_index field is relevant whenever custom matrices are used. It plays a similar role as the location field when the routing engine is used. So, all the objects have both of these fields to be used depending on the situation. However, I see that in the output, only the location field is present (in the unassigned key, and the step object).

The user-defined matrices and the location_index type of fields were introduced in v1.2.0. Do we have any reasons for omitting the location_index type of field from the output, or is it because this field was not required then, so was not added?

I feel that it would be better to also add the location_index index field in the unassigned key, and the step object in the output. Firstly, it would look more consistent - both the location and location_index fields could be present in the output, depending on whether the custom matrices or the routing engine is used. Secondly, getting the location index of the task in the output might be useful to the users who are using custom matrices. Obviously, the end-users can get the location index of the task manually, but I think it would be easy to do it in the vroom itself without adding any extra complexity.

If this looks okay, I would be happy to submit a PR. :-)

[jcoupey]

Technically, we provide a way to uniquely identify any task in output (step or unassigned) with type + id so users should be able to go back to their full description provided in input in the first place. In this sense, any additional information can be considered redundant. In order to avoid bloating the API, I've been trying to resist providing too much stuff in output "for convenience" and turned down such requests before, e.g. to feature initial constraints in output.

Now the first exception to this implicit rule is locations, which were included from the start for the sake of being able to simply plot a solution only from the output. I agree that not having location_index available in output while they are mandatory in input with custom matrices is not really consistent. So let's extend the location logic in output to location_index, of course only in the case where custom matrices are provided in input.

[jcoupey]

@krashish8 if you submit a PR appending some stuff to unassigned objects, you may want to kill two birds with one stone by handling "description" too, see #403. ;-)

[krashish8]

Actually, trying to kill "three" birds with one stone, where one bird is entirely different from the other two ;-)

Maybe it's not a good idea to kill different birds (issues) with a single stone (PR), but the changes were quite small, so I did. As a matter of fact, I'm getting rid of all the issues that I created here :-)

Please review: #627