Making Workflows Better

This will also serve as step 1 of documentation and drive further discussions.

## Activity Configuration
Each Activity is configured to have an 'order' property, and now `Activity` will implement Spring's `Ordered` interface:

```java
public interface Activity<T extends ProcessContext> extends BeanNameAware, Ordered
...
public abstract class BaseActivity<T extends ProcessContext implements Activity<T> {
    ...
    //activities that do not explicitly override this will go at the end
    protected int order = Ordered.HIGHEST_PRECEDENCE;

    public int getOrder() {
        return order;
    }
    
    public void setOrder(int order) {
        this.order = order;
    }
    ...
```

## `SequenceProcessor` Configuration
The `BaseProcessor` (from which `SequenceProcessor` extends) will now sort the lists based on Spring's `OrderComparator.INSTANCE`, which will be invoked during `afterPropertiesSet()`. This has the advantage of sorting in-place as well:
```java
@Override
public void afterPropertiesSet() throws Exception {
    OrderComparator.sort(activities);
}
```

## Framework Activities
The ordering defined for each Activity will use the '1000' range (1000, 2000, 3000, etc). This configuration would look like this as defined in bl-framework-applicationContext-workflow (this is the blPricingWorkflow):
```xml
<bean p:order="1000" id="blOfferActivity" class="org.broadleafcommerce.core.pricing.service.workflow.OfferActivity" />
<bean p:order="2000" id="blConsolidateFulfillmentFeesActivity" class="org.broadleafcommerce.core.pricing.service.workflow.ConsolidateFulfillmentFeesActivity" />
<bean p:order="3000" id="blFulfillmentItemPricingActivity" class="org.broadleafcommerce.core.pricing.service.workflow.FulfillmentItemPricingActivity" />
<bean p:order="4000" id="blFulfillmentGroupMerchandiseTotalActivity" class="org.broadleafcommerce.core.pricing.service.workflow.FulfillmentGroupMerchandiseTotalActivity" />
<bean p:order="5000" id="blFulfillmentGroupPricingActivity" class="org.broadleafcommerce.core.pricing.service.workflow.FulfillmentGroupPricingActivity" />
<bean p:order="6000" id="blShippingOfferActivity" class="org.broadleafcommerce.core.pricing.service.workflow.ShippingOfferActivity" />
<bean p:order="7000" id="blTaxActivity" class="org.broadleafcommerce.core.pricing.service.workflow.TaxActivity">
    <property name="taxModule" ref="blTaxModule"/>
</bean>
<bean p:order="8000" id="blTotalActivity" class="org.broadleafcommerce.core.pricing.service.workflow.TotalActivity" />
```

## Module Activities
Modules will use the 100 range to insert themselves in-between framework activities. For instance, the `addItemWorkflow` bean definition in the inventory module looks like this today:
```xml
<bean id="blAddItemWorkflow" class="org.broadleafcommerce.core.workflow.SequenceProcessor">
    <property name="processContextFactory">
        <bean class="org.broadleafcommerce.core.order.service.workflow.CartOperationProcessContextFactory"/>
    </property>
    <property name="activities">
        <list>
            <bean class="org.broadleafcommerce.core.order.service.workflow.add.ValidateAddRequestActivity"/>
            <bean class="org.broadleafcommerce.inventory.service.workflow.CheckAvailabilityActivity"/>
            <bean class="org.broadleafcommerce.core.order.service.workflow.add.AddOrderItemActivity"/>
            <bean class="org.broadleafcommerce.core.order.service.workflow.add.AddFulfillmentGroupItemActivity"/>
            <bean class="org.broadleafcommerce.core.order.service.workflow.PriceOrderIfNecessaryActivity"/>
            <bean class="org.broadleafcommerce.core.order.service.workflow.VerifyFulfillmentGroupItemsActivity"/>
        </list>
    </property>
    <property name="defaultErrorHandler" ref="blDefaultErrorHandler"/>
</bean>
```
This can now be refactored to something much much simpler:
```xml
<!-- Inject this activity in-between the first and second framework activities -->
<bean p:order="1100" id="blCheckAvailabilityActivity" class="org.broadleafcommerce.inventory.service.workflow.CheckAvailabilityActivity" />
<bean id="blAddItemWorkflow" class="org.broadleafcommerce.core.workflow.SequenceProcessor">
    <property name="activities">
        <list>
            <ref bean="blCheckAvailabilityActivity" />
        </list>
</bean>
```

In addition to using the 100 range for ordering, individual module activities will implement a `ModuleActivity` interface, which will tell the system that this particular activity has come from a module. Once the system detects this, the system will log at the support level the following:
    1. The fact that a module has modified a workflow
    2. The full and final configuration of the workflow

## Edge Cases
### 1. What if you want to replace a framework activity with your own implementation?
> Since all Activities will now be bean references, you should be able to redeclare as necessary

### 2. What if you want to change the ordering of a framework activity?
> The p:order elements should **not** undergo the merge process and thus will not be overridable in a project-specific applicationContext. This is preferred as there shouldn't really be a case for them doing that. However, if they REALLY want to override it, they can simply replace the bean definition and put whatever they want in the 'p:order' attribute.

### 3. What if a client configures an activity with the same order that we have in the framework or an additional module?
> No exception will be thrown but the fact that a module has injected an activity into a workflow will be logged at the support logging level. The ordering, by default, will be based in in-place order. Since the framework activities will come in first, the user activity will be sorted after the framework activity.

### 4. What if 2 modules configure activities in the same order? *(this is a very likely occurrence in a multi-module environment)*
> Same as 3. This shouldn't really be a problem because modules are not supposed to know about each other anyway and should be able to operate completely independently of each other. This means that a module should not care if another module also injects an activity in the same 'region' ordering (like both of them in the 1000 range). The only thing the module should care about in regards to workflows and activities is their activity in relation to the framework activities.

## Problems With the Approach
1. ~~The response to item 4 of the 'Edge Cases' section is very kluge. In order to really accomplish this, the user would have to subclass the bean definition of both of the module activities and then provide ordering for both of them~~
> Since 4 does not throw an exception, the only use case for this would be a user that wants very fine-grained control of these modules in concert with each other. In this case, they would simply redeclare the bean definition in XML and then provide their own property for 'p:order'
2.  ~~Simply setting an 'order' property and skipping by defined increments seems too 'loose' of a paradigm. Perhaps investing the extra time into how Spring orders security filters ('before', 'after', etc).~~
> Unfortunately, using an approach similar to this does not allow fine-grained control over the ordering in-between the framework activities. For instance, if you have 2 activities both declared 'before' a framework activity, then what determines the ordering between the 2?  Perhaps they would be put in declaration order, but what if you wanted to change that ordering? Too many edge cases surround this that cause it to not suit our needs.