api: Adding API path config and Request Detector

- Croogo.Api.path: denotes the URL path prefix for API requests

- CroogoRouter::isApiRequest()
  Verifies that all the necessary keys are present to qualify as an API request
api: Adding ApiRoute class

- Handle :api and :prefix in route path accordingly.

- Transforms 'prefixed' actions to a value recognized by Acl actionPath,
  eg: action `v1_0_index` is transformed into `index`, so by the time
  actionPath is generated it will be:

    `Controller/index` instead of `Controller/v1_0_index`
api: Acl - actionPath as 'api|controllers' based on routes

`actionPath`s are typically denoted as follows:

  `controllers/Plugin/Controller/action` or
  `controllers/Controller/action`

with `controllers` as the root of the ACO tree.

For API actions, ACOs will be created on a separate `api` ACO tree,
further split into separate versions: `api/version/Plugin/Controller/action`,
eg:

  `api/v1.0/Users/Users/index`
  `api/v1.1/Users/Users/index`
api: CroogoRouter::mapResources() helper method

Wraps Router::mapResources() with Croogo defaults
api: Adding Croogo::hookApiComponent()

Store list of API components in CroogoAppController::$apiComponents
api: Separate loading of components by type

Instead of directly modifying Controller::$components, the hook system
will store them separately in the following properties:

  * CroogoAppController::$appComponents
  * CroogoAppController::$apiComponents

CroogoAppController::_setupComponents() will then load a separate set of
components for normal vs API routes
api: Override CroogoAppController::invokeAction + BaseApiComponent
api: AclPermissions UI - display API tree in a separate tab
api: AclExtras - scan actions from BaseApi components
api: Implement /api/v1.0/users/lookup