Move processor and/or field settings to top-level properties on the index?

We should probably do this ASAP, to break as few installations as possible. (Since this will break all of them.)

The index should then also have setters for both that automatically sort the new settings. Currently, it seems that code is in the form submit handlers, where it of course doesn't belong.

OK, not ASAP, apparently.

Anyways, since I'm again struggling with fields and (static) caching: we could then resolve the whole problem by just loading the field objects once for the index, having them as the canonical representation of the fields (basically) and forbidding any direct access to the actual, stored $fields property, and then writing the field objects back to the stored property only when the index is saved.
It seems to me this could resolve a huge load of caching troubles.

Thanks for implementing this change!

However, I fear the timing isn't great, with #2574969: Add a Views-like UI for adding fields almost finished and changing a lot of the fields code, this is sure to require a lot of re-rolling work either way. I think committing the other one first and then re-rolling this one might be easier, but I'm not sure.

The patch itself looks of course mostly good, just two things:

1. I think the order "fields, processors, options" makes the most sense for the index properties. But, in any case, this should be uniform across the code.
2. I don't think getCachedFields() is a good new name for the method, the fact that they are cached should be mostly transparent to callers of the method, and in any case not have any effect on them. I propose getFieldObjects() in the attached patch, but actually I think the solution from the processors makes more sense – using [gs]etFieldSettings() for the new methods and keeping getFields() as-is. In any case, I don't see a reason why fields and processors would have different mechanisms there, this is just bound to lead to confusions.
   What would you say?

Thanks for the re-roll (or, rather, redo)! Looks pretty good, just a few style issues, as usual. (Mostly adjusting method order to my taste.)
The exception when trying to access/change the old options is a pretty good idea. However, we should be sure to remove it before the stable release, I don't think such code should be present there. In the meantime it could help a few people, though.

As per our IRC discussion, removed the exceptions and committed.
Thanks again for all your work on this!