Move Actions-related interfaces into their own packages for clarity

[JordanMartinez]

This is a proposal for how we could better separate the actions of the view/model from their implementations' code. In other words, rather than having a GenericStyledArea that is 1000 lines of code long, most of which is filled with properties, javadoc, and other implementation details, making it difficult for new users to figure out how to use the code immediately, we can move that to their own corresponding interface so that it's easier to find all the relevant methods one can call on an area.

• StyleableSequence was added so that a future GenericRichArea (non-styled area) could become the new base area more easily by simply removing that interface from the base classes and adding it to subclasses.
• The view (GenericStyledArea) could have two interfaces: 1) ViewActions for other view-related actions (e.g. scrolling, showing a specific line, etc.) and 2) ViewNavigation for other navigation that can only be done in the view, not model (e.g. lineStart/End, not paragraphStart/End in Update method & behavior: lineStart/End, not paragraphStart/End #419).
• Additionally, many methods currently implemented in StyledTextAreaBehavior (e.g. selectWord, deletePrevWord, deleteNextWord, etc.) could be added to these interfaces so that developers who are implementing their own custom behavior can create them much faster.

[JordanMartinez]

Can I get some feedback on this approach? A few questions I have:

• Virtualized defines its own estimatedScrollX/YProperty and totalWidth/HeightProperty. I would like these to be in ViewActions for two reasons: first, the getter/setters are not so easily hidden in the midst of the other properties getters/setters because the property stands out, and second, the javadoc for that property will be found in ViewActions, not the area itself, which continues to approach of defining all the view-related javadoc in one interface. If I add those methods in ViewActions, however, then I'm redefining the same method signature. So, I'm not sure whether this is desirable or not. If I don't, then I can only define the javadoc in the actual base area.
• I'm not sure what other methods should be in the ViewActions interface, and if any of that interface's methods should actually be in a different interface. On one hand, it would be better if all the view methods were found in the same interface. On another hand, splitting them up by category as the model's actions package does makes it easier to find things.
• Updated: Which methods in StyledTextAreaBehavior should be added to ViewActions as default methods? And how? For example, deletePrevWord requires both EditActions and NavigationActions. One could make a new interface for this, but that seems rather pointless... The first could extend the second, but then scope of that interface is polluted with the other's methods.

[JordanMartinez]

This was accomplished to a lesser degree of detailedness via #461.