Plugin system

## Motivation

The ability to specify plugins [similar to Glamor](https://github.com/threepointone/glamor/blob/master/docs/plugins.md).

## Basic example

I think a plugin system could be useful for aliasing prop names as well as take advantage of any caching the library may be doing.

This is just a rough idea, but plugins could be created through functions and all they would do is allow translation/resolution of what the incoming props mean. For example, this could be useful for libraries that may alter the CSS API with an API like Stack on top of Flexbox.

```js
import { css, plugin } from "otion";

const stackCss = plugin((prop, value) => {
switch (prop) {
case 'axis':
return ['flexDirection', prop === 'horizontal' ? 'row' : 'column']
default:
return [prop, value]
}
})

stackCss({ axis: 'horizontal' })
// returns .classname { flexDirection: row }
```

Since plugins are created from a function they scope the custom API but still resolve to the same atomic styles used elsewhere:

```js
import { css, stack, grid } from 'my-lib'

stack({ axis: 'horizontal' }) === css({ flexDirection: 'row' })
grid({ axis: 'horizontal' }) === css({ gridAutoFlow: 'row' })
```

The issue names no files, tests, or entry points; start by reading the linked Glamor plugin documentation and reviewing the existing css API shown in the examples. Before implementation, clarify the plugin contract, aliasing and translation behavior, and interaction with caching. Done requires an agreed design and validation of the stack and grid examples.

Written by the indexing model from the issue text.