turn deprecation warnings into errors

[corakingdon]

Steps:

1. Release v0.10.0 with the following depreciation warnings (using either @deprecate or Base.depwarn
2. Release v1.0.0 where these now error, mostly with a MethodException since methods will be removed. This will require cleaning out the deprecated code, any helper functions for deprecation warnings, and any tests of the now removed code.

Deprecations include the following (also search for Base.depwarn and @deprecate)

• Integer indexing into a TimestepArray at the time index position with getindex or setindex!
• using the functions is_time or is_timestep
• indexing into a simulation instance with square brackets
• changes that need to be made to set_param!
• type parameterization in @Defcomp New syntax in defcomp for datum type parameterization #638
• renaming marginal to modified in MarginalModel's
• change replace_comp! to replace! w/ julia argument convention (use pair)

[lrennels]

I think it's probably a good idea to add deprecation warnings to anything where it's a somewhat one to one change with functions, and then the rest of the things could be in a nice comprehensive list or something that we can post on the website/docs.

[lrennels]

In terms of indexing into a simulation index with square brackets, I have completely removed that getindex function and replaced it with a getdataframe, so we'd have to add the getindex back in if we wanted to deprecate it. I have a feeling no one is using that so it might not be necessary but either way would be fine.

[rjplevin]

If nobody is using it, the deprecation does no harm. If they are using it and you don't deprecate, it causes grief. Any reason to not deprecate? Seems like the better choice to me!

[lrennels]

Agreed, no reason not to deprecate except laziness, I'll go grab that old PR and add back in a deprecated getindex function!

[lrennels]

#713