Support sub file types

This PR implements a way of declaring different placeholders for the same kind of files.

## Reasoning

Bower [main property has been a struggle](https://github.com/bower/bower/issues/935) for a very very long time and it's unlikely that is [ever going to change](https://github.com/bower/bower.json-spec/issues/20). Meanwhile, the [Bower spec](https://github.com/bower/bower.json-spec) only specifies one way of consuming the required files from a package, using the **main** property.

Up until now, the way **wiredep** is working around the limitation of assets definition on Bower packages is by figuring out file types by their extension name and defining placeholders for each of them. This solution has been working great for simple cases but in some environments we really need to differentiate one kind of js file from another or have two different placeholders for css files for instance.

### The ie stylesheet limit problem

Our beloved _ie9_ has [very low limits on stylesheet files](http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164546.aspx) and in some situations we need to separate some css files from the minify build. In the actual implementation there is not a way of achieving such separation when using wiredep.

## The proposed solution

The solution implemented by this PR extends the file extension detection to allow package publishers to define a sub file type in order to _wiredep_ them into different placeholders.

In order to fix the issue in the _ie9 limit_ example, a package author with a very large css file could rename it to `style.notmin.css` that would be placed inside the `<!-- bower:notmin.css -->` placeholder. Allowing the user to keep using `<!-- bower:css -->` along with usemin and his other css files.

### Requirements

The only extra step required by the users in order to use a "sub file type" is declaring both the **detect**/**replace** patterns for the new type.

## Conclusion

This is an incremental change only that should be 100% backwards compatible. Any user not interested on defining sub file types would never be affected in any way - _in fact, the changes to the actual code are minor, a dozen lines or so_.

I see this as an essential addition for **wiredep** - thus the reason of such a detailed description. Sorry if it got too long.