I'm going to take these out of order, since some of the early lines refer to later ones. The bulk of the output is the Boot#### lines, which describe boot options.
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash
Your example output includes a large number of options like these, which have names but no further elaboration. These are likely built-in options on your specific firmware. In your case, these first three seem to be options to enter the firmware setup menu, to launch the built-in boot manager, and to display a diagnostic splash screen -- but really, there's no way to know for sure what they are, at least not from the efibootmgr output alone.
The numbers following the Boot string are in hexadecimal, and there's nothing special about any given number -- that is, Boot0000 is not reserved for any particular function, nor is Boot0001 or anything else. The numbers are assigned when a program creates a new boot entry, and the assignments are essentially meaningless. (At least, unless there's a bug; I know of some bugs that can make a firmware favor lower-numbered boot entries.)
Boot0003* ATA HDD2: WDC WD5000LPVT-08G33T1 ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000..bYVD.A...O.*..
Boot0004* ATA SSD1: SanDisk SSD U100 24GB ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000..bYVD.A...O.*..
These two options describe specific devices. After the Boot#### string comes a description that is human-interpretable, at least to a point -- you can see that these are two disk devices. The ACPI(...) and PCI(...) strings identify the hardware, and this information isn't readily interpreted by humans, except by cross-checking with other hardware information. Then there's some gibberish, which is encoded data for the entry that might or might not be easily read by humans. In this case, it's clearly not easily interpreted by people.
In most cases, when you see an entry like this that refers to a disk device, the reference is really to the fallback boot loader file (EFI/BOOT/bootx64.efi, at least on x86-64 systems) on the disk's EFI System Partition (ESP). EFI does not use boot loaders embedded in a disk's MBR, the way BIOS does.
Boot0005* RAID DEVICE2: 030a2500d23878bc820f604d8316c068ee79d25ba5388f9ca46ace40bf2f0ade9bc05d6d01
Boot0006* RAID DEVICE1: 030a2500d23878bc820f604d8316c068ee79d25ba5388f9ca46ace40bf2f0ade9bc05d6d00
Boot0007* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
These are clearly more hardware entries. I don't recognize the format for these entries. You can ignore the long strings; just know that they refer to hardware devices.
I'm omitting a few entries here, since they're more of the same....
Boot000B* PCI LAN: EFI Network (IPv4) ACPI(a0341d0,0)PCI(1c,1)PCI(0,0)MAC(089e01381698,0)IPv4(0.0.0.0:0<->0.0.0.0:0,0, 0x.J.+*.N.....=8.
This is a variant on the disk entries, but this one identifies a network device. Note that it includes a MAC address (MAC(...)) and specifies use of IPv4 (IPv4(...)). If this entry were to be booted, the computer would try to PXE-boot from a network server.
Boot000C* Lenovo Recovery System ACPI(a0341d0,0)PCI(1f,2)03120a00010000000000HD(3,276800,1f4000,26c6992a-07b8-43bc-98b8-d8c83e64db3b)File(\EFI\Microsoft\Boot\lrsBootMgr.efi)
Boot0010* Windows Boot Manager HD(2,1f4800,82000,72931328-061b-42e0-8fd8-8a5ac7775074)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................
These entries both identify EFI boot loaders stored on the hard disk. They do so with slightly different syntaxes -- note that the first begins with ACPI(...) and PCI(...) entries, as earlier ones did, whereas the second uses an HD(...) identifier. The latter includes a GUID for the partition, along with some other idenfications. Both entries include a filename (File(...)). The Windows entry includes more gibberish-like data at the end, but in this case it's a UTF-16 string that's passed to the boot loader as an option.
Your example includes a lot of entries. Many EFIs produce much shorter lists -- for instance, they may be missing the built-in options or the options for PXE-booting from the network. OTOH, sometimes you'll see other options, like entries that refer to BIOS-mode boots. Notably absent from your list was an entry for booting Ubuntu. Here's such an entry from one of my computers:
Boot000D* ubuntu HD(1,800,112800,a8d39218-44ce-455b-8735-919754df131d)File(\EFI\UBUNTU\GRUBX64.EFI)..BO
As you can see, that's pretty similar in basic form to the entry for the Windows boot loader, although of course the details differ. Your example may have been missing an Ubuntu entry because you haven't yet installed Ubuntu, because you installed Ubuntu in BIOS/CSM/legacy mode (a mistake), because your EFI is buggy and so efibootmgr was unable to add an entry, or because you explicitly deleted the entry once it was created. If you're having a boot problem, I recommend you ask another question and provide details.
The remaining entries follow these patterns. Now, backing up to the start....
ubuntu@ubuntu:~$ sudo efibootmgr -v
BootCurrent: 0008
The BootCurrent line identifies the entry that was used to boot the computer. In this case, it's Boot0008, which I snipped but which identifies a USB flash drive -- you booted using the fallback boot loader stored on that drive.
Timeout: 0 seconds
This line identifies the timeout on the EFI's built-in boot manager. In practice, it might or might not mean anything.
BootOrder: 0010,0003,0004,0005,0006,0008,0007,0009,000A,000B,001D
This line identifies the order in which boot entries are tried. In this case, the EFI will try booting with Boot0010 (the Windows boot manager). If that entry identifies a non-existent device or file, or if the boot program returns, then the firmware will try Boot0003 (your Western Digital hard disk). If that entry fails, it will try Boot0004 (your SanDisk SSD), and so on.
