Steps to reproduce:
- Install `stock_barcode`
- Create two product "aaa" and "bbb" with both of them being tracked by
  lots with the same lot number "123"
- Open the Inventory app and go to Configuration > Operation Types >
  Delivery Orders
- Enable Product in the Barcode App
- Go to the barcode app > Operations > Delivery Orders and click on New
- Scan 123
- Scan aaa (or bbb it probably depends on order of creation of product)
- Scan 123

Issues:
bbb has been added even though we never scanned it.

The reason for this bug is that when we scan 123 we don't have it in the
cache as such we make an RPC and store 123 in `missCache`.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L184-L185

After this when we scan aaa we retrieve the record, and add the line as
intended. The problem arise when we scan 123, since it's already in our
cache.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L130

However that record is not right since this lot is linked to the wrong
product bbb.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L135-L138

We will try to retrieve again the right record, however we will once
again get a hit on the cache. As such no RPC call will be made to
retrieve the lot we're looking for.

We will go in the function once again, where we will have the same
problem this time in the `if (model)` condition.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L112-L115

Later in the execution we will get to this line where we call the
function without a filters which will allow the wrong record to be
added.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/models/barcode_model.js#L943

The root of this problem lies in the way we set the key to the cache,
since two product can share the same barcode we need a more precise
cache key to differentiate them.

The proposed solutions is to cache result based on the provided
arguments to the function. This means fewer hit if we retrieve the same
record with different filter for example, however it's safer as when we
hit we are sure to get the right record.

opw-3862263

Forward-Port-Of: odoo/enterprise#63094
Forward-Port-Of: odoo/enterprise#61844

The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location.
But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue.

How to reproduce:
- Inventory -> Settings -> Enable "Multi-Step Routes";
- Go to your warehouse and choose 3 steps for incoming and/or outgoing shipments;
- Go to the Barcode App > Operations > Internal Transfers > New;
- In the newly created transfer, try to scan who is not a sublocation of WH/Stock (WH/input for example, barcode: WH-INPUT)
  - :arrow_right:  An error message is displayed because you are not allowed to scan this location.

The exact same issue happens for destination too since 61d378b0a49ba734cff84a39aa2693fe4226225d.

Also, fix a minor unrelated bug where locations on the barcode line are
not correctly written when there name include the picking's defaut
location's name (eg.: WH/Stock 2 when the default location is WH/Stock.)

[OPW-3843358](https://www.odoo.com/web#id=3843358&cids=1&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#63058
Forward-Port-Of: odoo/enterprise#62480

### Steps to reproduce:

With company 1:

- Go to the General Settings and activate: 
  1) Inter-Company Transactions: 
     - "Synchronize Sales and Purchase Order" 
     - "Automatic Validation" 
     - "Copy Lots on Delivery Validation" 
  2) Multi-Step Routes
- Go to Inventory > Configuration > Warehouse Management > Locations
- Create a new Location SHELF with COMP1/STOCK as parent
- Go to Inventory > Configuration > Warehouse Management > Putaway Rules
- Create a new putaway rule applicable to all products from COMP2/STOCK to COMP2/STOCK/SHELF

With company 2:

- Create a storable product tracked by a Unique Serial Number
- Click on "On Hand" > Register 1 on hand qty with a new serial Number
- Create and confirm an SO for company 2 with your product

At this point, if you go to company 1:

A purchase order related to the SO was created and confirmed. If you open the related delivery and inspect the related stock move line the destination, it will correctly be set to COMP1/STOCK/SHELF.

With company 2:

- Open the delivery linked to your SO click on the list icon of you stock move line
- Add a stock picking referencing the serial number you created
- Validate the delivery

If you go to company 1, the move line is now attached with a serial number but the destination is set to set to COMP1/STOCK.

#### > The putaway rule is not applied anymore

### Cause of the issue:

When you confirmed the SO with company 2, it will create an PO in company 1:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/sale_order.py#L22 and a related stock move will then be created. During the "_action_confirm" of this stock move the putaway rules will be applied to the stock move lines a few lines after creation: https://github.com/odoo/odoo/blob/58fefc94ca39f7951392063921fe9b5e606178e6/addons/stock/models/stock_move.py#L1720 When you confirm the delivery, this correclty set stock move line will be deleted and a new one will be created:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/stock_picking.py#L30-L33 However, as the "apply_putaway_strategy" method is not called after the creation of this newly created stock move line, the destination of the line will entirly be set by the destination of the stock move: https://github.com/odoo/odoo/blob/42b760c8fa27cfc75fcb2fd5b232defc9002e85f/addons/stock/models/stock_move.py#L1441 so that the put away rules will not be applied anymore.

opw-3744375

Forward-Port-Of: odoo/enterprise#62547
Forward-Port-Of: odoo/enterprise#60161