Now performs its parsing logic when using the setter mode.
Old `set_ship_from_address` changed to alias method.
Will deprecate this later.

Added as a temp solution while waiting for merge of #220 to formalize
(will then move to appropriate location)
Tests updated. Lots of tests that should raise exceptions no longer do by design.

Addresses concerns like #217, but currently incomplete.

…-amazon-mws into docs-inbound-shipments

similar to master incoming change

similar to master incoming changes
Removed TravisCI config
removed Makefile

Provides easier access to that utility within datatype classes

Better grouping with other methods.

Type hinting for all methods in InboundShipments class
Adjustments to isinstance checks,
now looking for generic Mapping and Iterable types
(note the renaming of IterableType and IterableAbc, to
avoid confusion between the collections.abc generic
and the typing colleciton)

Allows users to set the from_address on a per-request basis.
Tests modified to clear this option (coverage not up to par yet!)

Introduce the to_params method, part of the base class.
Request methods should call on to_params to return flat dict results
Internally, models require implementation of params_dict
to create params dict specific to the model.
Prefixes can be added by the prefix arg in `to_params`,
which will call flat_param_dict for completeness.

Need to replace item parsing with a model
for better handling in future
Docs need to reflect that change coming up.
For now, more details to be added on the shipment creation process.

Not being tested directly,
and it would be worthwhile to know if it breaks there for some odd reason
(unlikely, but never hurts)

…itself the same way as before.User can also skip this and use string literals.

Should be able to supply a sequence of InboundShipmentPlanRequestItem instances
to request method.
Adjustments to request method to accept this model forthcoming.
Main benefit: model can accept PrepDetails, unlike current arg parsing.

Small test overall, and it's for a minor piece of the tooling.
But, I figure ensuring this works as expected can help with
some potential legacy bugs in future.

Able to build an item of this model from a plan item DotDict instance.
Should aid in getting folks to inject the plan details for an item
so that they can use CreateInboundShipment
in a more streamlined setting.

Docs update to follow.

Kind of a missed opportunity there, not supplying useful values
for shipment status. Also setting the default to WORKING
helps newcomers create their working shipments
without forgetting anything.

Think this naming makes more sense in context.

`shipment_items_from_plan` can be used to process the contents of
`resp.parsed.InboundShipmentPlans.member` (typically part of a response
from a `InboundShipments.create_inbound_shipment_plan` request).
This converts the `Items` found in response content to a list of
`InboundShipmentItem` instances, ready to be passed to
`InboundShipments.create_inbound_shipment`.

To account for the lack of data for case-packs and pre-order item
release dates, function accepts the `overrides` argument, which expects
a dict of SKUs with either an `ExtraItemData` instance or another
dict with keys "quantity_in_case" and "release_date" (matching the
signature for the `InboundShipmentItem` constructor and the
`from_plan_item` alternate constructor).

With a set of overrides provided, SKUs in the planned shipment are
matched up, with the details from `overrides` injected into the new
`InboundShipmentItem` instance.

Tests have been added to cover the use cases for this function,
with some adjustment to fixtures to streamline that test code a bit.

Using this, a user can now gather items from a shipment plan
very simply like so:

    from mws.models.inbound_shipments import shipment_items_from_plan
    from mws.models.inbound_shipments import ExtraItemData

    # overrides can be constructed ahead of time to inject
    # case-pack and release date info.
    # No SKUs can be added to a shipment this way.
    # If using a standard dict, any keys not matching
    # quantity_in_case or release_date are ignored.
    overrides = {'mySku': ExtraItemData(...), ...}

    for plan in resp.parsed.InboundShipmentPlans.member:
        shipment_items = shipment_items_from_plan(
            plan, overrides=overrides,
        )
        inbound_api.create_inbound_shipment(
            ...,
            items=shipment_items,
            ...,
        )

More details to provided in a docs update coming shortly.

Takes us up to completion of creating an FBA shipment, including
different methods for gathering items from responses to
`create_inbound_shipment_plan`.

Beyond this content, may still want to add some details on updating
a shipment, shipment status, getting package labels, etc.
All of that is relevant, but remains a deep topic, and adding all that
to the same doc may be a bit much (already at 500+ lines here).

Reorganized imports across these modules using isort
(or rather VS Code command "Python Refactor: Sort Imports",
which calls on isort at the lower level)

Exploded argument lists in functions to multiple lines to aid in
readability. With some more complex type annotations in use, having
the arguments on multiple lines, even for a short set of args, makes
it a lot easier to decipher.

Changed some type hints from `Iterable` to `List`. No underlying code
change, but I think indicating the `List` type is easier than specifying
the more generic `Iterable`.

Added `utils.params.iterable_param` function. Replaces instances that
would follow this pattern:

    if not isinstance(val, (list, set, tuple):
        val = [val]

I just think it makes more sense to codify that usage under its own
utility, otherwise the code base is not very DRY.
Actual code is a bit more generic than previous examples, but boils down
to wrapping non-iterables in a list, with the exception that strings
are not counted as "iterables".

Some type annotations for request method arguments in InboundShipments
have been updated, as well as some docstrings that were incorrect.
More scrutiny needed here in near future, I think.

Moved back from the pattern of condensing `make_request` calls to single
lines if using a small set of data: now standardized on the pattern:

    data = {}
    return # request goes here.

Further expanded some other calls to utility methods, specifying the
argument names explicitly. This expands the number of code lines in
the module, sure, but leaves it more verbose and easier to read.

This may not necessarily be feasible for MWS requirements, but I cannot
think of the reason to leave these as required without a documented
reason to require them.
Therefore, when and if someone responds with an issue documenting
why some parts of this are *not* optional, then we can adjust it later.

At this stage, I am exhausted of this documentation.
I'm sure there's more that can be written, but I can't think of it
right now, and it's time to move on to other concerns instead of
holding this up and further.