Call For Action: standard library for Solidity

Call For Action: "Standard Solidity Library"

Solidity is quickly improving thanks to the work of everyone involved. The compiler is getting in a better shape every day and providing the low level features nicely, however support for higher level features still needs to improve. Many have created helper functions, but all these efforts are scattered around in different places.

I have created a tree called [density](https://github.com/axic/density) as a start to this effort. So far it contains a very limited set of features:
- the two missing bitwise operators (shl, shr)
- the basic design patterns (owned, mortal and interface)
- interfaces for the standard contract APIs (so far, token only)

I've did the above a week ago, but only pushed it now. I have also some string utilities, such as conversion of address to string, which I haven't committed yet.

I wasn't able to find everything via Google before, but now more and more such snippets have surfaced. Either I'm getting bad at using Google or it is harder to get meaningful results out of it. The following "libraries" already exists out there:
- dapp-bin/library has a few utilities already (strings, linked list, and recently [two](https://github.com/ethereum/dapp-bin/pull/48) [pull](https://github.com/ethereum/dapp-bin/pull/49) requests for maths)
- the oraclize.it API has a few string related functions
- the ether.camp IDE has a snippet called std.sol

**I think the standard library should contain**:
- the basic design patterns (owner only, mortal, etc.)
- interfaces for the [Standardized Contract APIs](https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs)
- useful string helpers
- support for bitwise operators until EVM and Solidity supports it natively
- have a basic math library (which also supports ‘floating points’ to at least 2 decimal places) (also, FIXME: define "basic")
- has other basic helpers in place for conversion between types (those which aren’t natively supported)

I don’t think it should go into dapp-bin, but a separate tree for the library only. And that tree probably should belong to an org on github as opposed to a person.

**The questions are**:
- what structure should it have (a lot of questions here)?
- what should be included?
- what should be the goal for the code (readability/understandability, effectiveness i.e. gas cost, ..)?
- what license should it be under (safe to assume MIT, as every piece of code involved is already under it)?
- what should it be named?
- where should such a library be placed?
- anything else?

Based on git history, the following users have contributed to the libraries: @chriseth, @fivedogit, @obscuren, @bertani, @pipermerriam. Calling all you guys for input.

Appendix A. - List of useful helpers
- https://github.com/ethereum/dapp-bin/tree/master/library
- http://dev.oraclize.it/api.sol (string and number parsing)
- https://github.com/pipermerriam/ethereum-string-utils
- https://github.com/pipermerriam/ethereum-stack-depth-lib
- https://github.com/pipermerriam/ethereum-datetime
- https://github.com/axic/density (bitwise, address to string)
- https://github.com/pipermerriam/ethereum-murmur-hash

No repository file or test is named. Start by reviewing the density tree, dapp-bin/library, and the listed helper and API references, then use the issue's questions to establish the library's structure, contents, goals, license, name, and location. Done requires an agreed scope and project home rather than a single code change.

Written by the indexing model from the issue text.