create a format virtual function for the format api

[netanelgonen]

Description

• Type: Enhancement
• Related issue: #4886
• Priority: Major

Enhancement

currently each FS type will have it's own static functio to format, in this case the user need to know the FS type while he wants to format, moving from FS to FS will have change the code just for this API since all other function are virtual with good abstraction for all FS.

this request is following a discussion between @sg- and @geky from mbed-os and @avolinski and I from pal team

[geky]

This is a very interesting C++ puzzle: Accessing a static function of a class from a virtual interface.

Here's what I can think of:

1. Just provide a non-static virtual option that calls the static function through the virtual inheritance:

   /** Virtual access to format
    *
    *  @param bd     Block device to format
    *  @returns      0 on success, negative error code on failure
    */
   virtual int format_(BlockDevice *bd) {
       return MyFileSystem::format(bd);
   }

   This doesn't sit well with the intention of virtual functions, but is the simpliest option. Also note this only works because our C++ classes don't follow RAII.

2. Add a getter for the format function

   /** Get the format function for the related filesystem
    *
    *  @returns      The format function as a callback. @see format for additional documentation.
    */
   virtual Callback<int(BlockDevice*)> get_formatter() {
       return &MyFileSystem::format;
   }

   This seems like the "correct" approach, but can end up a bit messy. Also requires implementors to understand the callback class.

---

Although, I've been thinking about what @netanelgonen and I have discussed. And in the long run, it seems like it will be much simpler to just move logic PAL needs directly into the FileSystem class.

I've raised a pr with the details here: #4908

This would reduce the number of functions we will need to support, and provides a quick route to brute-forcing a filesystem (instead of this).

If we go with the reformat, we can drop #4886, although we will still need the FilePath change to get a physical FileSystem.

[geky]

@netanelgonen, #4908 was merged today. It is currently available on master, and is planned to be available in 5.6.0.

Let us know if you run into any problems with the api.