MSI Source support for flags that control "can ship from source" and "accepts returns"

Nobody has claimed this yet.

### Description (*)
To date the MSI project has added a lot (I even read somewhere it is 30% of all core code?) ... good work. In our M1 system we have been using several multistock solutions and kind of learned along the way. One of the things however we are missing in M2 MSI is that currently a warehouse can be either enabled/or not ... on and off. In essence this influences the salabilty. Can the products be sold from this source?

However in several store situations we have seen different behaviors of sources where there is more granularity "exactly what a source location can do" some examples include. I will list some examples of the extra granularity and add some situations. See under expected behavior.

### Expected behavior (*)

Sources have additional core settings controlling the behavior of the source not only for sales, but also for returns and shippability

`enabled` - this is the master switch for a source. If on then the source is added into queries, logic, but if turned off then all the below settings are overridden to no or disabled.

`salable` - a source can be salable and this means the qtys in that source are added in the formula for salable qty

`can ship from source` - sometimes sources have a special function and can be used to ship from during shipping, but not to sale from on the frontend or backend. And example is an "INC - Incoming source" where backordered products or new (season) products are received; or maybe an "RES - Restore source" where products in some kind of return or fix state are stored until they can be sold again. An admin may want to ship from it if necessary, but does not want to sell from it on the backend.

`accepts returns` - in a later stage we imagine MSI will also have some kind of logic to select to "which" source a return is sent. Often there is some logic that differs for order items before they are shipped (goes back to same source -selected by default-, but a dropdown should exist to select which source) and after they are shipped (goes back to some RES- Restoration source -selected by default-, but a dropdown should exist to select which source)

`not salable only for admin` - in some cases one would not want to sell products from the frontend, but a source can only be used by admins creating an order in he backend.


### Benefits

Customer situations may exist where sources exist that behave like, e.g.

- INC Incoming source: source where backordered products belonging to some waiting order are scanned and received. Item stock is updated +1 upn receival and the "waiting" orders can be shipped. Items from this source for example may not be sold (a second time) on the frontend nor on the backend. The source settings may look like this


- RES - Restoration or fix source. When returns are processed they are sometimes sent back to the originating source. But actuall y in most cases this wont happen. In real merchant life there is always an in-beween state where returns maybe are "reviewed before going back into salable stock" or "need to be reconditioned before going into salable stock" or "need to be fixed before going into salable stock". To me Magento has always been close to our real life processes and I see this as a missing feature that can easily be added. The source settings may look like this


### Additional information
Many examples exist in M1 extensions and use cases that somehow never reached the MSI project which is interesting as these are real life examples that affect us every day. It would really be great if these situations and use cases for merchants are also covered by the core.

Some examples may be gathered from reviewing this extension: https://www.safemage.com/multi-warehouse-inventory.html

No files, tests, or entry points are named. Start by reviewing the existing MSI source settings and the referenced extension for comparable behavior. Done means source configuration supports the requested enabled, salable, shipping, returns, and admin-only distinctions with the stated overrides and workflows.

Written by the indexing model from the issue text.