Make MefFile accessors names more standard

[kabasset]

Here is the current list of MefFile accessors:

const T& access(long index);
const Hdu& operator[](long index);
const T& accessFirst(const std::string& name, long version = 0);
const T& access(const std::string& name, long version = 0);
const ImageHdu& primary();

For homogeneity and standardization, they could be renamed as:

const T& as(long index);
const Hdu& operator[](long index);
const T& find(const std::string& name, long version = 0);
const T& as(const std::string& name, long version = 0);
const ImageHdu& primary();

where as<T>() denotes the requirement to access the only available such HDU (analogously to RecordVec where keywords must not be duplicated), while find<T>() stops when one HDU matches.
Find could even be open to user functions.

// Given two extensions:
// - 1: named "FOO" with version 1 and no data
// - 2: named "FOO" with version 2 and some data
const auto hdu = f.as<ImageRaster>(1); // 1
const auto hdu = f.as<ImageRaster>("FOO"); // Throws
const auto hdu = f.find<ImageRaster>("FOO"); // 1
const auto hdu = f.find<ImageRaster>("FOO", 2); // 2
const auto hdu = f.find<ImageRaster>("FOO", 0, [](const auto& hdu) { return hdu.readSize() > 0; }); // 2

[kabasset]

After careful consideration, as() looks a bit awkward. Access is more expressive to me, and:

const auto hdu = f.access<ImageRaster>(1);
// Access the image data unit of index 1

reads better than:

const auto hdu = f.as<ImageRaster>(1);
// As an image data unit, access the HDU of index 1

Standard tuples use get() which would be a bit inaccurate here, as what we "get" is not a data unit but a handle to it, and the MefFile is the owner; access doesn't convey the message that the user gets ownership.

find() is fine, though.

[kabasset]

A bit of inspiration:

• from Python's ElementTree: operator[](), get(), find(), findall(), append(), insert(), remove(), index(), iter(), iterFind();
• from nlohmann's json: operator[](), get<>(), at(), iter()