Description of the issue/feature this PR addresses:

The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of the main warehouse location should be considered as a out move. The inverse condition doesn't make much sense.

Current behavior before PR:
Let's use a simple example:

- create a new product.
- create an outgoing movement from shelf 1.
- click on "Replenisment" menu. No orderpoint for the new product.

![image](https://github.com/odoo/odoo/assets/23449160/02033177-205f-4720-88a6-08086f4c23b3)



Desired behavior after PR is merged:

A new orderpoint should have been created at WH/Stock for that product. See below with the fix:

![image](https://github.com/odoo/odoo/assets/23449160/c13bd827-d0be-4605-b750-52059c9cb991)

@ForgeFlow

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#157287
Forward-Port-Of: odoo/odoo#156903

Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking where there is a shipping connector involved (i.e. when the `choose_delivery_package` wizard is opened).

Because the ability to handle this situation is now added to stable, we have to sort of support it now and handle it not breaking other flows. Here are the flows that need to be handled (and were broken by the previous PR): [In all cases, "Packages" setting needs to be activated and each picking needs at least 1 move of a consumable/storable product]

Flow 1: batch picking + put in pack for single picking
- Create 2 pickings of any operation type
- Create a new batch picking with these 2 pickings
- Open 1 of those pickings directly (i.e. not in the batch)
- Click on "Put in Pack"

Expected result:
Only the move from the open picking is put into a package

Result before this commit:
Both pickings have their moves put into the same package

Additional notes: Because this is not an obvious bug, users may already had this bug occur in their DBs without realizing it

===

Flow 2: batch picking (or multi-record calling of `action_put_in_pack`)
- Create 2 receipt pickings (or any picking where picking_type_id.show_reserved != False)
- Create a new batch picking with these 2 pickings
- Open batch picking + click "Put in Pack"

Expected result:
All moves in the batch are put into a package

Result before this commit:
Stack trace because self.immediate_transfer is a boolean and cannot be called for more than 2 records (i.e. breaks singleton check)

Additional notes:
In theory batch picking creation has checks to avoid batches where there are pickings with more than 1 picking type or have different `show_reserved` values, but because `_package_move_lines` is a method that can be called in different use cases (including multi-record pickings) via customizations/future code changes, we add in checks to prevent put in pack from finishing in those cases to avoid unexpected behavior/stack traces. I.e. remember to respect existing `self.ensure_one` checks since they're probably there for a reason.

===

Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where none = a different carrier than having 1)
- Create 2 delivery pickings with different `carrier_id` values (i.e. different shipping methods assigned to them)
- Add both pickings to a batch
- Click "Put in Pack" in the batch picking

Expected result:
None, we should not handle this case because if the products are in the same package then the same package info will be sent to both carriers and the user will be double charged for every move (or charged(/potentially create the wrong shipping documents) when it shouldn't be in case of no carrier for one of the pickings)

Result before this commit:
All moves are put in the same package and the double charging/potentially incorrect shipping documents will occur

Additional notes:
This is the use case that was intended to be avoided when flow was originally decided to not be handled

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#157224
Forward-Port-Of: odoo/odoo#156068

### Steps to reproduce:
- Install **Sales**, **Accounting** and **Inventory** apps.
- Go to **Inventory** > **Configuration** > **Products** > **Product Categories**.
- Open **All / Saleable / Office Furniture** and:
	- Set the Inventory Valuation as **Automated**
	- Set the Costing Method as **First In First Out (FIFO)**
- Go to **Inventory** > **Reporting** > **Inventory Valuation**
- Open the toggle header then Click on the plus button at the header.
- In the popup shown -Notice how the current value is 0-, set:
	- Added Value to **1000**
	- Counterpart Account to **600000 Expenses**
- Click on **REVALUE**, a new report appears.
- Open the newly created report > **Other Info**, open the **Journal Entry**.
- In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`.

### Investigation:
- the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34
- Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids`
- When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field
- That's why now `current_value_svl` is the _new_ value and not the _old_ one.

opw-3715522

Forward-Port-Of: odoo/odoo#154239