feat: improve operation messages and make them stateful

[bswck]

Pull Request Check List

• Added tests for changed code.
• Updated documentation for changed code.

This PR proposes more meaningful messages on installation operations:

• "Writing lock file" was displayed after writing the lock file. Now the message is "Lock file written", but I'm happy to adapt to a different idea that introduces past tense.
  The key is to convey the true state of the lock file; looking at

  poetry/src/poetry/installation/installer.py

  Lines 350 to 354 in fe9f85b

  	updated_lock = self._locker.set_lock_data(self._package, repo.packages)
  	if updated_lock:
  	self._io.write_line("")
  	self._io.write_line("<info>Writing lock file</>")

  
  one could easily observe that the "Writing lock file" message is written if updated_lock is truthy—and can only be after actually completing writing the lock file:
  

  poetry/src/poetry/packages/locker.py

  Lines 251 to 259 in fe9f85b

  	def set_lock_data(self, root: Package, packages: list[Package]) -> bool:
  	"""Store lock data and eventually persist to the lock file"""
  	lock = self._compute_lock_data(root, packages)
  	if self._should_write(lock):
  	self._write_lock_data(lock)
  	return True
  	return False

  
  

  poetry/src/poetry/packages/locker.py

  Lines 309 to 313 in fe9f85b

  	def _write_lock_data(self, data: TOMLDocument) -> None:
  	lockfile = TOMLFile(self.lock)
  	lockfile.write(data)
  	self._lock_data = None

  
  Where TOMLFile.write() atomically writes to the file.
• In terminals supporting ANSI output, the "Installing the current project" message shifts to "Installed the current project" when finished.
• Operation objects were partially stateful (e.g. held the skipped attribute) and now are fully stateful (store the information about whether they are in the done, warning or error state). Different attribute names ideas are welcome.
• Executor.get_operation_message() was deprecated and polymorphism was utilized in lieu of it. The new implementation was made to be 100% equivalent except that after the relevant operations finish, their messages use past tense in ANSI supporting cases–instead of freezing at "Downgrading" if Update(...).done is True, "Downgraded" is written eventually, etc.
• Instead of "Removing... (...): Removing..." and similar messages for other job types, one will now read "Removing ... (...): In progress..." as long as the operation is in progress. Other ideas welcome.

Before this can eventually be merged, we need a new GIF in the Poetry readme. @neersighted could you help with that?

[bswck]

I recorded "before and after" with asciinema for poetry add pydantic and poetry remove pydantic commands in the poetry repo.
What concerns me is that the operation messages starting with hyphens no longer become MarkDown bullet points.
(Ignore the a command and the sync-pre-commit-lock extension).

Before	After

[Secrus]

Could we have this stateful as well? Like, Writing lock file changing to Lock file written once the operation is done?

[bswck]

Well then, I guess that a new IO section would be needed and the

poetry/src/poetry/packages/locker.py

Lines 255 to 257 in fe9f85b

	if self._should_write(lock):
	self._write_lock_data(lock)
	return True

snippet would probably have to be rewritten to

     if self._should_write(lock): 
         section = ...
         section.write_line("<info>Writing lock file</>")
         self._write_lock_data(lock) 
         section.write_line("<info>Lock file written</>")  # or <success>Lock file written</>
         return True 

Is it worth the cost? It would require introducing a side effect in _write_lock_file or adding some extra logic to set_lock_data. IO writes are quite fast in contrary to installation operations; the only advantage it would bring is that it could inform about a potentially (but very rarely) erroneous action taken (in case the write fails) useful as a context for a traceback following the message.

[Secrus]

Ok, then maybe we could do something like Writing lock file... Done. where Done. appears after the operation is finished?

[bswck]

Ok, then maybe we could do something like Writing lock file... Done. where Done. appears after the operation is finished?

I think that would be inconsistent with the rest of the UI. Also, would it address the issue with additional logic/necessity of introducing new _write_lock_file side effects somehow?