process and encode methods: add equivalent to VisitResult

Nobody has claimed this yet.

this is typical implementation of custom component's method:

```
**MyComponent.java**MyComponent.processDecodes:

if (!isRendered()) {
return;
}
super.processDecodes(context);
// do specific stuff
```

If MyComponent extends UIInput, then if component has ValueExpression for "rendered" (and VE resolves to true), it is evaluated 3x:

1. MyComponent.processDecodes
2. javax.faces.component.UIInput.processDecodes(FacesContext)
3. javax.faces.component.UIComponentBase.processDecodes(FacesContext)

Suggestion:
add a useful return value for execute and render lifecycle methods like visitTree has already. Then code can be optimized:

```
**MyComponent.java**MyComponent.processDecodes:

if (!super.processDecodes(context))
return;

// do specific stuff
```

Considerations:

* Blake's Axiom of Boolean Properties: You will regret making your property a boolean ([http://www.mail-archive.com/dev@myfaces.apache.org/msg52753.html](http://www.mail-archive.com/dev@myfaces.apache.org/msg52753.html)). Create new Enum or reuse existing VisitResult as return value
* if change to exiting API is not possible, add new method like "UIComponent.isXYZPhaseExecutable"
* if change to API is not possible at all, find a way similar as ELContext.setPropertyResolved(boolean): a property on context "current execute/render method is executable on this component"
#### Affected Versions
[2.2]

Start by reviewing the UIComponent processDecodes, processValidators, and processUpdates lifecycle methods alongside visitTree and VisitResult. The issue presents several possible API designs rather than a selected approach, so first determine whether the lifecycle API can change and which return semantics would be acceptable; done would require an agreed design and corresponding API and compatibility work.

Written by the indexing model from the issue text.