Yul object names with dots are accepted but ambiguous

## Description

An identifier like `A.B.C` is a valid name for a Yul object. However, the compiler also uses dots as separators in qualified object/data names. This creates ambiguity when names with dots are passed to builtins like `dataoffset()` or `datasize()`.

Such names are interpreted as paths by some parts of the compiler and as names by other parts. This results in errors or ICEs unless both possibilities are defined. And when both are defined, it's possible that some checks are getting bypassed.

## Environment

- Compiler version: 0.8.28

## Steps to Reproduce

### Unreferenced object
`unreferenced.yul`
```yul
object "A.B.C" {
code {}
}
```
```bash
solc --strict-assembly unreferenced.yul --asm --debug-info none
```
```
======= unreferenced.yul (EVM) =======

Text representation:
stop
```

Dots in names are accepted and apparently cause no issue on their own.

### Top-level subobject
`top-level.yul`:
```yul
object "X" {
code {
sstore(0, datasize("A.B"))
}

data "A.B" hex"11223344556677"
}
```
```bash
solc --strict-assembly top-level.yul --asm
```
```
Error: Unknown data object "A.B".
--> top-level.yul:3:28:
|
3 | sstore(0, datasize("A.B"))
| ^^^^^
```

The error is coming from Yul analysis, which means that it treats it as a path and expects a nested subobject.

### Nested subobject
`nested.yul`:
```yul
object "X" {
code {
sstore(0, datasize("A.B"))
}

object "A" {
code {}

data "B" hex"112233"
}
}
```
```bash
solc --strict-assembly nested.yul --asm
```
```
======= nested.yul (EVM) =======
Uncaught exception:
/solidity/libyul/Object.cpp(155): Throw in function std::vector solidity::yul::Object::pathToSubObject(solidity::yul::YulString) const
Dynamic exception type: boost::wrapexcept
std::exception::what: Assembly object not found or does not contain code.
[solidity::util::tag_comment*] = Assembly object not found or does not contain code.
```

This one probably passes Yul analysis but then fails later at a place that interprets the path differently.

### Ambiguous subobject
`ambiguous.yul`:
```yul
object "X" {
code {
sstore(0, datasize("A.B"))
}

data "A.B" hex"11223344556677"

object "A" {
code {}

data "B" hex"112233"
}
}
```
```bash
solc --strict-assembly ambiguous.yul --asm --debug-info none
```
```
======= ambiguous.yul (EVM) =======

Text representation:
0x07
0x00
sstore
stop
stop
data_c304e60a0d3af7489b64bc5b186db2aed0df052c89a05935e0731015cd85d049 11223344556677

sub_0: assembly {
stop
stop
data_50fceab2fe7ed15023d21b343e098d8a822f44ed61ba7e988e708db9c68c2535 112233
}
```

Note the `0x07` - when assembling we're apparently choosing the top-level `data`, again different from analysis.

Reproduce the three cases in unreferenced.yul, top-level.yul, nested.yul, and ambiguous.yul with solc --strict-assembly. Start with Yul analysis and solidity/libyul/Object.cpp, especially pathToSubObject, then trace how assembly resolves the same names. Done means dotted object and data names have one consistent, non-ambiguous outcome without errors or ICEs.

Written by the indexing model from the issue text.