Improved delayed saving

[difanta]

Delayed saving did not work very well after #162, here are some improvements that make it work in most cases.

1. The bulk of the code changes are just clean ups: reorder arguments in some functions, rename datasetIdx -> intentIdx, move inlinePresentationSpec logic to the top of buildFillResponse, usernameAutofillIds and usernameAutofillContent data structures merged into usernameAutofillData as a pair of Id and nullable content, same for passwordAutofillIds and Content.
2. Allow parsing multiple fillContexts, this is very useful for login pages with separate username and password pages. AssistStructureParser now takes a list of AssistStructure and parses them starting from the most recent one. In the autofill service it is used in two ways: "helper" is the AssistStructureParser for only the current fillContext, "delayed_helper" is for all fillContexts put together. All the logic for autofill uses the current "helper", while only when saving data "delayed_helper" is used to get the most recent value for the username and passwords among all fill contexts (starting from the most recent).
3. Only add to username fields to usernameAutofillData if their id is not already in the list, same for passwords.
4. A default username is passed and showed in the form when creating a new password directly from autofill and "delayed_helper" contains a valid username.
5. Delayed saving logic was changed to the recommended one by the documentation in SaveInfo.

The saving logic now goes as follows:

When building the SaveInfo object while responding to a fill request:

• set as required the username field if unique, set as only optional the username fields if there are more than one
• same for password fields
• set FLAG_DELAY_SAVE if there are no password fields
• if there are no fields at all do not set the save info

When processing a save request, meaning the user interacted with the dialog and pressed "save":

• Get the most recent, non empty autofill text for username fields and password fields among all fill contexts (from "delayed_helper")

The behavior of the delayed save depends on the specific site, and even more in getting the parsing correct. In general if the DELAY_SAVE flag is set, the save dialog will not appear in the current page but only in the next one, if the user navigates away form the application and comes back after a while that information is lost. Also if the flag is not set when it should, information about the first page might be lost depending on what the system decides to send to the next fill request (only if the flag is set the information is guaranteed to be sent). And finally if the flag is set when it shouldn't it prevents the save dialog (eg. username only logins), but there is no workaround for this that I'm aware.