Modifies example configs' movement to 1000 to match range distribution in book

[colinhanrahan]

Current repo:

• An agent's functional range is the min of their vision and movement.
• In practice, if both are random variables from 1 to 10, the range distribution will be slanted with range 1 having a 19% chance and range 10 having only a 1% chance.
• This does not follow the book. Because they use one variable for both, book agents have a uniform range distribution with every integer in the interval being equally likely.

Changes:

• Updated README, "true default" settings in sugarscape.py, and config.json to use single-variable range by default. Movement is set to 9999 and vision is used as the deciding variable.
• I chose vision rather than movement because agents having comically large vision might imply that they have more information than they actually do. It's more intuitive for them to have limited vision and the ability to move wherever they want inside of that vision.
• Removed movement from all example configs so that they will correctly use single-variable range distributions. Removing all default settings from example configs for clarity will be a separate PR.

[nkremerh]

Sorry to do this to you, but do this the other way around. Our implementation of Sugarscape adds new functionality by splitting vision and movement. We shouldn't handicap our features out-of-the-box to what the book has. Instead, we should adjust our examples to match the more limited scope of the book.

[nkremerh]

Also set it to 1000 rather than 9999. The latter case could be misinterpreted as our logical max in the code being 9999 rather than the max size of an integer in the system. They're both equally comic in size.

[colinhanrahan]

@nkremerh Done. Where should we add the note about why we're using a comically large value (if we are adding a note)? Adding it to every single example might be a bit much.

[nkremerh]

No need for additional comment. At most, we may put a note in the wiki or a second README inside the examples directory. A second README sounds more appealing since it's self-contained in the repo on download, but we don't need that right now.