feat: add AutoIncrementing contract

[shrugs]

/**
 * @title AutoIncrementing
 * @author Matt Condon (@shrugs)
 * @dev Provides an auto-incrementing uint256 id acquired by the `nextId` getter.
 * Use this for issuing ERC721Token Ids or keeping track of request ids, anything you want, really.
 * @notice Does not allow an Id of 0, which is popularly used to signify a null state in solidity.
 */

[frangio]

I feel like this would be better as a library with a struct, so that a contract could have more than one auto-incrementing number. Structs don't have private fields though, so that would blow out the nice encapsulation, but I don't think it's too big a deal.

[shrugs]

@frangio can you explain in more detail what you mean?

[frangio]

Yes, sorry for the terseness. 🙇‍♂️

What I wanted to say is that implementing this functionality by inheritance doesn't feel right to me. The main reason why I feel this way is that it only allows for one auto-incrementing counter per contract. Conceptually, "auto-incrementing counter" is a new datatype, with an operation "next", so I would expect to be able to create several instances of it.

Solidity allows the creation of new datatypes using libraries and structs. In this case it would be something like:

struct Counter {
    uint256 _prev;
}

function next(Counter counter) internal returns (uint256);

Used as:

Counter private ids;
...
    uint256 newId = ids.next();

This enables having multiple counters and doesn't add to the inheritance graph of a contract. On the other hand, whereas the contract implementation in this PR is nicely encapsulated by having the nextId_ be private, structs don't have private members, and users of the struct can modify its members arbitrarily.

I think Solidity should have private struct members, but that isn't there yet. (Is there even an issue?) In the meantime, I think I still prefer the struct implementation to the inheritance one.

Thoughts?

[shrugs]

@frangio I've update the contract using that spec, and I like it better! Can you give it a last review?

[frangio]

Looks nice!

I'd prefer to keep the linting changes on unrelated files out of this PR.

[frangio]

LOL. It's actually physically impossible (as in not enough energy in the universe-impossible) to overflow a counter like this. This line is funny though, maybe we can just add in parenthesis that for reals it will never overflow so that people don't worry unnecessarily.

[shrugs]

fixed!